Вы увидите диалоговое окно, которое позволит вам создать элемент ‹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
‹/dependentAssembly›
‹/assemblyBinding›
‹/runtime›
‹/configuration›
Анализ внутренней структуры GAC
Итак, все работает. Теперь давайте посмотрим на внутреннюю структуру 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 с одинаковыми названиями.
Файлы политики публикации компоновочных блоков
Следующий вопрос, который мы должны рассмотреть в рамках обсуждения возможностей конфигурации, это роль