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:MyAsmsCarLibrary.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> может оказаться полезным при ссылках на компоновочные блоки, размещенные в сети на удаленной машине. Предположим, что у нас есть доступ к папке, размещенной по адресу http://www.intertechTraining.com. В таком случае для загрузки удаленного файла *.dll в кэш загрузки GAC на локальной машине следует изменить элемент <codeBase> так.
<codeBase version="2.0.0.0" href="http://www.IntertechTraining.com/Assemblies/CarLibrary.dll" />
Исходный код. Проект 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));
for (int i = 0; i ‹ numbOfTimes; i++) Console.WriteLine("Йо!");
Console.ReadLine();
}
}
Тип класса AppSettingsReader не задает способа записи специальных данных приложения в файл *.config. На первый взгляд это может показаться ограничением, но на самом деле это вполне логично. Сама идея создания файла *.config заключается в том, чтобы он содержал доступные только для чтения данные, которые должны помочь среде CLR (а также типу AppSettingsReader) правильно установить приложение на соответствующей машине.
Замечание. В ходе нашего обсуждения ADO.NET (см. главу 22) вы узнаете об элементе конфигурации ‹connectionStrings› и о других типах пространства имен System.Configuration. Эти элементы, появившиеся в .NET 2.0, предлагают стандартный метод обработки строк соединений.
Исходный код. Проект AppConfigReaderApp размещен в подкаталоге, соответствующем главе 11.
Файл конфигурации машины
Файлы конфигурации, которые мы с вами рассмотрели в этой главе, имеют одно общее свойство: они относятся к конкретному приложению (вот почему они имеют то же имя, что и соответствующее приложение). Но каждая поддерживающая .NET машина имеет еще и файл, имеющий имя machine.config, который содержит множество параметров конфигурации для управления работой всей платформы .NET (многие из этих параметров не имеют ничего общего с разрешением ссылок на внешние компоновочные блоки).
Платформа .NET использует файл *.config для каждой своей версии, установленной на локальной машине. Файл machine.config для .NET2.0 можно найти в каталоге C:WINDOWSMicrosoft.NETFrameworkv2.0.50727CONFIG (номер вашей версии может быть другим). Открыв указанный файл, вы увидите множество XML-элементов, задающих установки ASP.NET, различные параметры безопасности, поддержку отладки и т.д. Но если вы захотите добавить в файл machine.config (с помощью элемента ‹appSettings›) установки для приложений, применимые в рамках всей машины, вы можете сделать и это.
Этот файл можно редактировать непосредственно, используя программу Блокнот, но следует иметь в виду, что при некорректном изменении этого файла вы можете нарушить работу среды выполнения. Ошибки в этом сценарии могут иметь гораздо более серьезные последствия, чем ошибки в файле *.config приложения, поскольку ошибки XML в файле конфигурации приложения влияют только на данное приложение, в то время как неправильный XML-код в файле machine.config может вообще блокировать работу конкретной версии .NET.
Общая схема связей компоновочных блоков
Теперь, когда мы с вами изучили подробности того, как среда CLR осуществляет поиск запрошенных компоновочных блоков, вспомните о том, что простое на самом деле должно быть простым. Многие (если не все) ваши .NET-приложения будут иметь вид группы приватных компоновочных блоков, размещенных в одном каталоге. В таком случае достаточно просто скопировать соответствующую папку туда, куда требуется, и начать выполнение клиента.
Рис. 11.29. Метод разрешения ссылок компоновочного блока в среде CLR
Однако, вы уже видели, что в процессе разрешения связей среда CLR выполняет проверку на наличие файлов конфигурации клиента и политики публикации компоновочных блоков. В качестве общей схемы пути, который проходит среда CLR при разрешении внешних ссылок компоновочного блока, предлагается схема, показанная на рис. 11.29.
Резюме
Эта глава посвящена тому, как среда CLR разрешает ссылки на внешние компоновочные блоки. Глава начинается с рассмотрения содержимого компоновочного блока: заголовка, метаданных, манифеста и CIL-кода. Затем рассматриваются создание одномодульных и многомодульных компоновочных блоков, а также нескольких приложении клиента (на разных языках).
Вы смогли убедиться в том, что компоновочные блоки бывают приватными и общедоступными. Приватные компоновочные блоки копируются в подкаталог клиента. Общедоступные компоновочные блоки устанавливаются в глобальный кэш компоновочных блоков (GAC), и при этом они должны быть строго именованными. Наконец, вы узнали о том, что приватные и общедоступные компоновочные блоки можно конфигурировать, используя XML-файлы конфигурации клиента или, как альтернативу, файл политики публикации.
