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

Замечание. Если значение, присвоенное в рамках элемента ‹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="#"file:///C:\MyAsms\CarLibrary.dll" />
 </dependentAssembly>
 </assemblyBinding>
 </runtime>
</configuration>

Как видите, элемент <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> так.

<codeBase version="2.0.0.0" href="#" />

Исходный код. Проект CodeBaseClient размещен в подкаталоге, соответствующем главе 11.

Пространство имен System.Configuration

До этого времени все файлы *.config, показанные в этой главе, состояли из из­вестных XML-элементов, по которым среда CLR выясняла адреса внешних компо­новочных блоков. Вдобавок кэтим элементам файл конфигурации клиента может содержать и специальные данные приложения, не имеющие никакого отношения к установке связей. С учетом сказанного становится ясно, почему в .NET Framework используется пространство имен, которое позволяет считывать данные файла кон­фигурации клиента программными средствами.

Пространство имен Sуstem.Configuration определяет небольшой набор типов, которые можно использовать для чтения пользовательских установок из файла *.config клиента. Эти пользовательские установки должны задаваться в контексте элемента <appSettings>. Элемент <appSettings> может содержать произвольное числа элементов <add>, определяющих пары ключей и значений, которые могут извлекаться программными средствами.

Предположим, что у нас есть файл *.сonfig дата консольного приложения AppConfigReaderApp, в котором определяется строка связи с базой данных и ука­затель на данные timesToSayHello.

<configuration>
 <appSettings>
 <add key="AppConStr" value="server=localhost;uid='sa';pwd='';database=Cars" />
 <add key="timeToSayHello" value="8" />
 </appSettings>
</сonfiguration>

Чтение этих значений для использования приложением клиента осуществляет­ся простым вызовом метода экземпляра GetValue типа System.Configuration. AppSettingsReader. Как показывает следующий пример программного кода, пер­вый параметр: GetValue задает имя ключа в файле *.config, а второй параметр представляет соответствующий тип ключа (получаемый в C# в результате применении операции typeof).

class Program {
 static void Main(string[] args) {
 // Создание средства чтения и получение строки соединения.
 AppSettingsReader ar = new AppSettingsReader;
 Console.WriteLine(ar.GetValue("appConstr", typeof(string)));
 // Получение числа повторений приветствия и выполнение.
 int numbOfTimes = (int)ar.GetValue("timesToSayHello", typeof(int));