Язык программирования С# 2005 и платформа .NET 2.0. полностью

Тип класса 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:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG (номер вашей версии может быть другим). Открыв указанный файл, вы увидите множество 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-файлы конфигурации клиента или, как альтернативу, файл политики публикации.