Шрифт:
Замечание. Строго говоря, элемент ‹codeBase› можно использовать и для зондирования компоновочных блоков, которые не являются строго именованными. Однако в таком случае адрес компоновочного блока должен задаваться относительно каталога приложения клиента (в этом отношении данный элемент предлагает более широкие возможности, чем элемент ‹privatePath›).
Создайте консольное приложение с именем СodeBaseСlient, установите для него ссылку на CarLibrary.dll версии 2.0.0.0 и измените исходный файл так.
Поскольку библиотека CarLibrary.dll была установлена в структуру GAC, вы уже можете выполнить программу. Но для демонстрации применения элемента ‹codeBase› создайте новую папку на своем диске C (например, папку C:\MyAsms) и поместите в эту папку копию CarLibrary.dll версии 2.0.0.0.
Теперь добавьте в проект CodeBaseClient файл App.config (в соответствии с инструкциями, предложенными в этой главе выше) и добавьте в этот файл следующее XML-содержимое (не забывайте о том, что ваше значение .publickeytoken будет другим, и вы можете выяснить его в структуре GAC).
Как видите, элемент <codeBase> вложен в элемент <assemblyIdentity>, использующий атрибуты name и publicKeyToken для указания понятного имени компоновочного блока и соответствующего кода открытого ключа. Сам элемент <codeBase> указывает версию и (с помощью атрибута href) адрес загружаемого компоновочного блока. Если вы удалите CarLibrary.dll версии 2.0.0.0 из структуры GAC, этот клиент все равно будет выполняться успешно, поскольку среда CLR сможет найти внешний компоновочный блок в C:\MyAsms.
Однако если вы удалите каталог MyAsms со своей машины, то клиент работать не сможет. Очевидно, что элементы <codeBase> (если таковые присутствуют) имеют преимущество по сравнению с проверкой GAC.
Замечание. Если размещать компоновочные блоки в случайных местах на машине, велика вероятность того, что у вас, в конце концов, возникнет необходимость воссоздания реестра системы (из-за соответствующих проблем DLL), поскольку при перемещении или переименовании папок, содержащих выполняемые двоичные файлы приложений, имеющиеся связи будут нарушаться. В связи с этим используйте <codeBase> с осторожностью.
Элемент <codeBase> может оказаться полезным при ссылках на компоновочные блоки, размещенные в сети на удаленной машине. Предположим, что у нас есть доступ к папке, размещенной по адресуВ таком случае для загрузки удаленного файла *.dll в кэш загрузки GAC на локальной машине следует изменить элемент <codeBase> так.
Исходный код. Проект CodeBaseClient размещен в подкаталоге, соответствующем главе 11.
Пространство имен System.Configuration
До этого времени все файлы *.config, показанные в этой главе, состояли из известных XML-элементов, по которым среда CLR выясняла адреса внешних компоновочных блоков. Вдобавок кэтим элементам файл конфигурации клиента может содержать и специальные данные приложения, не имеющие никакого отношения к установке связей. С учетом сказанного становится ясно, почему в .NET Framework используется пространство имен, которое позволяет считывать данные файла конфигурации клиента программными средствами.
Пространство имен Sуstem.Configuration определяет небольшой набор типов, которые можно использовать для чтения пользовательских установок из файла *.config клиента. Эти пользовательские установки должны задаваться в контексте элемента <appSettings>. Элемент <appSettings> может содержать произвольное числа элементов <add>, определяющих пары ключей и значений, которые могут извлекаться программными средствами.
Предположим, что у нас есть файл *.сonfig дата консольного приложения AppConfigReaderApp, в котором определяется строка связи с базой данных и указатель на данные timesToSayHello.