Язык программирования С# 2005 и платформа .NET 2.0. полностью

Теперь предположим, что вы (как администратор системы) установили файл политики публикации (и новую, более позднюю версию компоновочного блока) на машине клиента. Как обычно и случается, девять из десяти соответствующих приложений перешли к использованию версии 2.0.0.0 без всяких ошибок. Однако в одном из приложений клиента при доступе к CarLibrary.dll версии 2.0.0.0 возникли проблемы (мы с вами знаем, что создать программное обеспечение, которое будет демонстрировать 100%-ную обратную совместимость, практически невозможно).

В таком случае можно построить файл конфигурации для данного "проблемного" клиента с инструкциями, которые позволят среде CLR игнорировать установленные в GAC файлы политики публикации. При этом другие приложения клиента, которые могут использовать новый компоновочный блок .NET, с помощью установленного файла политики публикации будут перенаправлены на новый компоновочный блок. Чтобы отключить политику публикации для отдельного клиента, создайте файл *.сonfig (с подходящим именем), в котором рамках элемента ‹publisherPolicy› установите для атрибута apply значение no. После этого среда CLR будет загружать компоновочный блок той версии, которая указана в манифесте клиента.

‹configuratоn›

 ‹runtime›

  ‹assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"›

   ‹publisherPolicy apply="no" /›

  ‹/assemblуВinding›

 ‹/runtime›

‹/configuration›

Файлы конфигурации приложения могут также указать базовый программный код. С помощью элемента ‹codeBase› можно дать инструкцию среде CLR искать зависимые компоновочные блоки в указанных местах (например, в общей сетевой папке или в локальном каталоге вне каталога приложения клиента).

Замечание. Если значение, присвоенное в рамках элемента ‹codeBase›, указывает на удаленную машину, компоновочный блок будет загружен по требованию в специальный каталог структуры GAC, имеющий специальное название – кэш загрузки. Увидеть содержимое кэша загрузки можно с помощью gacutil.exe, указав при запуске этой утилиты опцию /ldl.

С учетом того, что вы уже знаете об установке компоновочных блоков в GAC, будет ясно, что компоновочные блоки, загружаемые с помощью элемента ‹codeBase›, должны быть строго именованными (в конце концов, как же иначе среда CLR смогла бы установить удаленные компоновочные блоки в структуру GAC?).

Замечание. Строго говоря, элемент ‹codeBase› можно использовать и для зондирования компоновочных блоков, которые не являются строго именованными. Однако в таком случае адрес компоновочного блока должен задаваться относительно каталога приложения клиента (в этом отношении данный элемент предлагает более широкие возможности, чем элемент ‹privatePath›).

Создайте консольное приложение с именем СodeBaseСlient, установите для него ссылку на CarLibrary.dll версии 2.0.0.0 и измените исходный файл так.

using CarLibrary;

namespace CodeBaseClient {

 class Program {

  static void Main(string[] args) {

   Console.WriteLine("***** Забавы с CodeBase *****");

   SportsCar с = new SportsCar();

   Console.WriteLine("Создана спортивная машина.");

   Console.ReadLine();

  }

 }

}

Поскольку библиотека CarLibrary.dll была установлена в структуру GAC, вы уже можете выполнить программу. Но для демонстрации применения элемента ‹codeBase› создайте новую папку на своем диске C (например, папку C:\MyAsms) и поместите в эту папку копию CarLibrary.dll версии 2.0.0.0.

Теперь добавьте в проект CodeBaseClient файл App.config (в соответствии с инструкциями, предложенными в этой главе выше) и добавьте в этот файл следующее XML-содержимое (не забывайте о том, что ваше значение .publickeytoken будет другим, и вы можете выяснить его в структуре GAC).

‹configuration›

 ‹runtime›

  ‹assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"›

   ‹dependentAssembly›

    ‹assemblyIdentity name="SharedAssembly" publicKeyToken="191ebf55656e0a43." /›

     ‹codeBase version="2.0.0.0" href="href="file:///C:\MyAsms\CarLibrary.dll" />