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

В каталоге приложения SharedCarLibClient создайте новый файл конфигурации SharedCarLibClient.exe.config и поместите в него следующие XML-данные. Конечно, значение вашего открытого ключа будет отличаться от того, которое содержится в показанном ниже примере программного кода, но это значение вы можете выяснить путем просмотра манифеста клиента с помощью ildasm.exe или в структуре GAC.

‹configuration›

‹runtime›

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

‹dependentAssembly›

‹assemblyIdentity name="CarLibrary" publicKeyToken="191ebf55656e0a43" culture="/›

‹bindingRedirect oldVersion= "1.0.0.0" newVersion= "2.0.0.0"/›

‹/dependentAssembly›

‹/assemblyBinding›

‹/runtime›

‹/configuration›

Снова выполните программу SharedCarLibClient.exe. Вы должны увидеть сообщение о том, что загружена версия 2.0.0.0. Если же для атрибута newVersion вы укажете значение 1.0.0.0 (или просто удалите файл *.config), будет загружена версия 1.0.0.0. поскольку среда CLR найдет в манифесте клиента указание о том, что необходимо использовать версию 1.0.0.0.

В файле конфигурации клиента может присутствовать несколько элементов ‹dependentAssembly›. В нашем случае никакой необходимости в этом нет, но предположим, что манифест SharedCarLibClient.exe ссылается также на общедоступный компоновочный блок MathLibrary версии 2.6.0.0. Если вы захотите перенаправить клиент на использование MathLibrary версии 3.0.0.0 (вдобавок к использованию CarLibrary версии 2.0.0.0), то в этом случае файл SharedCarLibClient.exe.config должен выглядеть так.

‹configuration›

‹runtime›

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

‹dependentAssembly›

‹assemblyIdentity name="CarLibrary" publicKeyToken="191ebf55656e0a43" culture="/›

‹bindingRedirect oldVersion= "1.0.0.0" newVersion= "2.0.0.0"/›

‹/dependentAssembly›

‹dependentAssembly›

‹assemblyIdentity name="MathLibrary" publicKeyToken="191ebf55656e0a43" culture="/›

‹bindingRedirect oldVersion="2.5.0.0" newVersion= "3.0.0.0"/›

‹/dependentAssembly›

‹/assemblyBinding›

‹/runtime›

‹/configuration›

Вы вправе надеяться, что должна быть какая-то возможность генерирования файлов *.config общедоступных компоновочных блоков с помощью средств графического интерфейса утилиты .NET Framework 2.0 Configuration. Подобно построению файла *.сonfig для приватных компоновочных блоков, первый шагом здесь является ссылка на соответствующий файл *.exe, для которого выполняется конфигурация. Для примера удалите только что созданный вами файл SharedCarLibClient.exe.config. Теперь в окне утилиты .NET Framework 2.0 Configuration добавьте ссылку на SharedCarLibClient.exe, щелкнув правой кнопкой мыши в строке узла Applications (Приложения). Затем раскройте пиктограмму (+) и выберите подузел Configured Assemblies (Сконфигурированные компоновочные блоки). После этого щелкните на ссылке Configure an Assembly (Сконфигурировать компоновочный блок) в правой части окна утилиты.

Вы увидите диалоговое окно, которое позволит вам создать элемент ‹dependentAssembly› с помощью ряда элементов графического интерфейса. Сначала с помощью кнопки переключателя выберите Choose an assembly from the list of assemblies this application uses (Выбрать компоновочный блок из списка компоновочных блоков, используемых данным приложением), что, по сути, означает требование показать манифест. Затем щелкните на кнопке Choose Assembly (Выбрать компоновочный блок).

Появившееся диалоговое окно отобразит не только компоновочные блоки, явно указанные в манифесте клиента, но и компоновочные блоки, на которые указанные компоновочные блоки ссылаются. Для нашего примера выберите CarLibrary. После щелчка на кнопке Finish (Готово) будет показана страница свойств для выбранного объекта манифеста клиента. Там, используя возможности вкладки Binding Policy (Политика привязки ресурсов), вы сможете сгенерировать ‹dependentAssembly›.

На вкладке Binding Policy вы можете установить значения атрибута oldVersion (укажите 1.0.0.0) в текстовом поле Requested Version (Запрошенная версия) и атрибута newVersion (2.0.0.0) текстовом поле New Version (Новая версия). После ввода указанных параметров, вы обнаружите следующий файл конфигурации, сгенерированный для вас системой.

‹?xml version="1.0"?›

‹configuration›

‹runtime›

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

‹dependentAssembly›

‹assemblyIdentity name="CarLibrary" publicKeyToken="l91ebf55656e0a43" /›

‹publisherPolicy аррlу="yes" /›

‹bindingRedirect oldVersion = "1.0.0.0" newVersion="2.0.0.0" /›

‹/dependentAssembly›

‹/assemblyBinding›

‹/runtime›

‹/configuration›

Итак, все работает. Теперь давайте посмотрим на внутреннюю структуру GAC. При просмотре папки GAG в программе Проводник Windows вы видите ряд пиктограмм, изображающих каждый из общедоступных компоновочных блоков всех имеющихся версий. Эта графическая оболочка обеспечивается COM-сервером shfusion.dll. Но, как вы можете подозревать, за этими пиктограммами должна скрываться сложная (хотя и вполне логичная) структура каталогов.

Чтобы понять, что на самом деле представляет собой структура GAC, откройте окно командной строки и перейдите в каталог assembly.

cd c:\windows\assembly

Выберите в командной строке команду dir. В этом каталоге, среди прочего, вы обнаружите папку с названием GAC_MISL (рис. 11.26).

Рис. 11.26. Скрытый подкаталог GAC_MSIL

Перейдите в каталог GAC_MSIL и снова выберите команду dir. Теперь вы увидите список подкаталогов, которые имеют в точности такие же имена, как и пиктограммы, отображаемые сервером shfusion.dll. Перейдите в подкаталог CarLibrary и снова выберите команду dir (рис. 11.27).

Рис. 11.27. Внутри скрытого подкаталога CarLibrary

Как видите, в структуре GAC для каждой версии общедоступного компоновочного блока создается свой подкаталог, имя которого выбирается по правилу ‹версияКомпоновочногоБлока›__кодОткрытогоКлюча. Если из текущего каталога вы перейдете в каталог CarLibrarу версии 1.0.0.0, то обнаружите там копию соответствующей библиотеки программного кода (рис .11.28).

Рис. 11.28. Смотрите! Внутренняя копия GAC библиотеки CarLibrary.dll!

При установке строго именованного компоновочного блока в структуру GAC операционная система расширяет структуру путем создания специального подкаталога в системном каталоге assembly. При таком подходе среда CLR может использовать разные версии, компоновочных блоков, избегая конфликтов, которые иначе могли бы возникать из-за наличия файлов *.dll с одинаковыми названиями.

Следующий вопрос, который мы должны рассмотреть в рамках обсуждения возможностей конфигурации, это роль политики публикации компоновочных блоков. Вы только что убедились, что с помощью файлов *. config можно выполнить привязку к конкретной версии общедоступного компоновочного блока в обход версии, указанной в манифесте клиента. Все это просто прекрасно, но представьте себе, что вы являетесь администратором, которому придется переконфигурировать все приложения клиента на данной машине так, чтобы эти приложения использовали компоновочный блок CarLibrary.dll версии 2.0.0.0. Ввиду принятого соглашения для имен файлов конфигурации, вам придется многократно копировать одно и то же XML-содержимое во множество мест (еще и предполагается, что вы должны знать, где находятся все файлы, использующие CarLibrary!). Очевидно, что для администратора это будет просто кошмаром.