Читать онлайн «ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание». Страница 99

Обратите особое внимание на то, что элемент ‹probing› не указывает, какой компоновочный блок размещается в соответствующем подкаталоге. Поэтому вы не можете сказать, что "CarLibrary размещается в подкаталоге MyLibraries, a MathUtils – в подкаталоге Bin". Элемент ‹probing› просто дает среде CLR "инструкцию" при поиске запрошенного компоновочного блока исследовать указанные подкаталоги, пока не обнаружится первое совпадение.

Замечание. Атрибут privatePath нельзя использовать для указания ни абсолютного (C:\Папка\Подпапка), ни относительного (…\\ОднаПапка\\ДругаяПапка) пути! Если вы хотите указать каталог вне пределов каталога приложения-клиента, вам придется использовать другой XML-элемент – элемент ‹codeBase› (дополнительные подробности об этом элементе будут приведены в этой же главе немного позже).

Чтобы указать с помощью атрибута privatePath множество подкаталогов, используйте список значений, разделенных точками с запятой. В данный момент у вас в этом нет никакой необходимости, но вот вам пример, в котором CLR дается указание проверить подкаталоги клиента MyLibraries и MyLibraries\Tests.

‹probing privatePath="MyLibraries; MyLibraries\Tests"/›

После создания CSharpCarClient.exe.config выполните приложение-клиент с помощью двойного щелчка на выполняемом файле в программе Проводник Windows. Вы должны обнаружить, что теперь CSharpCarClient.exe выполняется без проблем (если это не так, проверьте введенные данные на отсутствие опечаток).

Затем, с целью проверки, измените (произвольным образом) имя файла конфигурации и попытайтесь выполнить программу еще раз. Приложение-клиент должно выдать отказ. Вспомните о том, что файл *.config должен иметь префикс, соответствующий имени приложения-клиента. В качестве последней проверки откройте свой файл конфигурации для редактирования и перепишите любой из XML-элементов символами верхнего регистра. После сохранения файла выполнение вашего клиента должно стать невозможным (поскольку язык XML является чувствительным к регистру символов).

Вы, конечно, можете всегда создавать XML-файлы конфигурации вручную с помощью своего любимого текстового редактора, но Visual Studio 2005 позволяет создать файл конфигурации в процессе построения программы-клиента. Для примера загрузите в Visual Studio 2005 проект CSharpCarClient и добавьте в него новый элемент Application Configuration File (Файл конфигурации приложения), выбрав Project→Add New Item из меню. Перед тем как щелкнуть на кнопке ОК, обратите внимание на то, что файл получит название App.config (не переименовывайте его!). Если после этого заглянуть в окно Solution Explorer (Обозреватель решений), то вы увидите, что в текущий проект добавлен файл App.config (см. рис. 11.12).

Рис. 11.12. Файл App.config в Visual Studio 2005

После этого вы сможете ввести все необходимые XML-элементы для создаваемого клиента. И здесь следует отметать кое-что действительно интересное. Каждый раз при компиляции проекта Visual Studio 2005 будет автоматически копировать данные App.config в каталог \Bin\Debug, назначая копии имя с учетом соответствующего соглашения о назначении имен (например, имя CSharpCarClient.exe.config). Однако это происходит только в том случае, когда файл конфигураций называется Арр.config. При этом вам придется поддерживать только App.config, a Visual Studio 2005 гарантирует, что каталог приложения будет содержать самые последние и самые полные данные (даже если вы, например, переименуете свой проект).

Создание файлов *.config вручную не является слишком большой проблемой, но, тем не менее, .NET Framework 2.0 SDK предлагает инструмент, который позволяет строить XML-файлы конфигурации в рамках графического интерфейса пользователя. Утилиту Microsoft .NET Framework 2.0 Configuration можно найти в папке Администрирование, размещенной в панели управления Windows. Запустив этот инструмент, вы увидите ряд опций конфигурации (рис. 11.13).

Рис 11.13. Утилита конфигурации .NET Framework 2.0 Configuration

Чтобы построить файл *.config клиента с помощью этой утилиты, первым шагом должно быть добавление того приложения, которое будет конфигурироваться. Для этого щелчком правой кнопки мыши откройте контекстное меню узла Applications (Приложения) и выберите пункт Add (Добавить). В появившемся диалоговом окне вы можете обнаружить приложение для конфигурации при условии, что оно выполнялось ранее с помощью программы Проводник Windows. Если это не так, щелкните на кнопке Other (Другие) и зайдите в папку программы-клиента, которую вы хотите конфигурировать. Для данного примера следует выбрать приложение VbNetCarClient.exe, созданное в этой главе ранее (поищите его в папке Bin). После этого вы должны увидеть новый дочерний узел, как показано на рис. 11.14.

Рис. 11.14. Подготовка к изменению конфигурации VbNetCarClient.exe

Если щелкнуть правой кнопкой мыши на узле VbNetCarClient и активизировать пункт контекстного меню Свойства, то внизу появившегося диалогового окна вы увидите текстовое поле, где можно ввести значения, которые будут приписаны атрибуту privatePath. Просто для проверки введите имя подкаталога TestDir (рис. 11.15).

Рис. 11.15. Указание приватного пути зондирования в рамках графического интерфейса

После щелчка на кнопке ОК вы можете посмотреть в каталог VbNetCarClient\ Debug и убедиться, что в типовой файл *.сonfig (который Visual Studio 2005 создает для программ VB .NET) был добавлен нужный элемент ‹probing›.

Замечание. Как вы можете догадаться сами, XML-содержимое, сгенерированное утилитой конфигурации .NET Framework 2.0, можно скопировать в файл App.config Visual Studio 2005 для дальнейшего редактирования. Позволяя инструментам автоматизации генерировать начальное содержимое, вы, очевидно, уменьшаете для себя объем вводимого с клавиатуры текста.

Теперь, когда вы понимаете, как инсталлировать и конфигурировать приватные компоновочные блоки, мы с вами можем приступить к рассмотрению роли общедоступных компоновочных блоков. Подобно приватному компоновочному блоку, общедоступный компоновочный блок представляет собой набор типов и (возможно) ресурсов. Самой очевидной особенностью общедоступных компоновочных блоков, в отличие от приватных, является то, что одна и та же копия общедоступного компоновочного блока может использоваться разными приложениями.

Так, многие приложения в этой книге указывают ссылку на System.Windows.Forms.dll. Но если заглянуть в каталоги этих приложений, вы не обнаружите там приватные копии этого компоновочного блока .NET. Причина в том, что System.Windows.Forms.dll инсталлируется, как общедоступный компоновочный блок. Очевидно, что именно такой подход нужна использовать при создании библиотеки классов, используемой на уровне всей машины.

Общедоступный компоновочный блок не инсталлируется в каталог использующего его приложения. Общедоступные компоновочные блоки устанавливаются в GAC (Global Assembly Cache – глобальный кэш компоновочных блоков). Каталог GAC является подкаталогом с именем assembly в корневом каталоге Windows (например, C:\Windows\assembly), как показано на рис. 11.16.

Рис. 11.16. Глобальный кэш компоновочных блоков

Замечание. Выполняемые компоновочные блоки (*.exe) устанавливать в каталог GAC нельзя. Общедоступными компоновочными блоками могут быть только блоки, имеющие вид *.dll.

Перед установкой компоновочного блока в GAC вы должны назначить компоновочному блоку строгое имя, которое уникальным образом идентифицирует издателя данного двоичного объекта .NET. При этом следует понимать, что "издателем" может быть и отдельный программист, и подразделение в рамках отдельной компании, и отдельная компания целиком.

В некотором смысле строгое имя является современным .NET-эквивалентом схемы GUID-идентификации COM. Если вы имеете опыт работы с COM, вспомните о том, что AppID (идентификатор приложения) – это GUID (Globally Unique IDentifter – глобальный уникальный идентификатор), характеризующий конкретное COM-приложение. В отличие от GUID-значений в COM (которые являются ничем иным, как 128-разрядными числами), строгие имена создаются на основе двух связанных криптографических ключей (называемых открытым ключом и секретным ключом). Поэтому строгие имена оказываются гораздо более стойкими в отношении искажений и должны быть ближе к уникальности, чем простые GUID-значения.

Формально строгое имя компонуется из набора связанных данных, в большинстве своем задаваемых следующими атрибутами уровня компоновочного блока.

• Понятное имя компоновочного блока (которое, напоминаем, является именем компоновочного блока без расширения файла)

• Номер версии компоновочного блока (назначаемый с помощью атрибута [AssemblyVersion])