Эндрю Троелсен - ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

Политика публикации позволяет "издателю" данного компоновочного блока (вам, вашему подразделению, вашей компании или другому конкретному поставщику) предложить бинарную версию файла *.config, которая устанавливается в структуру GAC вместе с новейшей версией соответствующе-то компоновочного блока. Преимущество такого подхода в том, что тогда отпадает необходимость в наличии специальных файлов *.config в каталогах приложений клиента. Среда CLR читает текущий манифест и пытается найти запрошенную версию в структуре GAC. Но если при этом среда CLR обнаруживает файл политики публикации, читаются встроенные в этот файл XML-данные и выполняется соответствующее перенаправление на уровне GAC.

Файлы политики публикации создаются средствами командной строки с помощью .NET-утилиты al.exe (это редактор связей компоновочного блока). Этот инструмент имеет очень много опций, но для построения файла политики публикации потребуются указать только следующие данные:

• информацию о размещении файла *.config или *.xml, содержащего инструкции перенаправления;

• имя файла, задающего новые параметры политики публикации;

• информацию о размещении файла *.snk, используемого для создания подписи файла политики публикации;

• номера версии, назначаемой создаваемому файлу политики публикации.

Чтобы построить файл политики публикации, контролирующий библиотеку CarLibrary.dll, нужно использовать следующую команду.

al /link: CarLibraryPolicy.xml /out:policy.1.0.CarLibrary.dll /keyf: C:\MyKey\myKey.snk /v:1.0.0.0

Здесь XML-содержимое включено в файл с именем CarLibraryPolicy.xml. Имя выходного файла, которое должно иметь формат policy.‹главный(номер версии)›. ‹дополнителъный(номер версии)›.конфигурируемыйКомпоновочныйБлок), указывается с помощью флага /out. Обратите также внимание на то, что имя файла, содержащего значения открытого и секретного ключей, тоже должно быть представлено, но с помощью опции /keyf. (Поскольку файлы политики публикации являются общедоступными, они должны быть строго именованными.)

В результате использования al.exe вы получите новый компоновочный блок, который можно разместить в структуре GAC для того, чтобы, не используя отдельные файлы конфигурации для каждого приложения, "заставить" все клиенты использовать CarLibrary.dll версии 2.0.0.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" />

Как видите, элемент вложен в элемент , ис­пользующий атрибуты name и publicKeyToken для указания понятного имени компоновочного блока и соответствующего кода открытого ключа. Сам элемент указывает версию и (с помощью атрибута href) адрес загружаемого компоновочного блока. Если вы удалите CarLibrary.dll версии 2.0.0.0 из струк­туры GAC, этот клиент все равно будет выполняться успешно, поскольку среда CLR сможет найти внешний компоновочный блок в C:\MyAsms.