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

  Console.ReadLine()

 End Sub

End Module

Чтобы скомпилировать этот выполняемый компоновочный блок с командной строки, используйте компилятор командной строки Visual Basic .NET vbc.exe со следующим набором команд.

vbc /r:airvehicles.dll *.vb

Обратите внимание на то, что при ссылке на многомодульный компоновочный блок компилятору нужно указать только имя первичного модуля (файлы *.netmodule загружаются по запросу программного кода клиента). В самих файлах *.netmodules нет индивидуального номера версии, и они не могут непосредственно загружаться средой CLR Файл *. netmodule может загружаться только первичным модулем (например, файлом, содержащим манифест компоновочного блока).

Замечание. В Visual Studio 2005 позволяется ссылаться и на многомодульные компоновочные блоки. Используйте диалоговое окно Add Reference и выберите первичный модуль, В результате будут скопированы и все связанные файлы *.netmodule.

К этому моменту вы должны чувствовать себя вполне уверенно при построении как одномодульных, так и многомодульных компоновочных блоков. Конечно, можно утверждать, что с вероятностью 99.99 % ваши компоновочные блоки будут одномодульными. Однако и многомодульные компоновочные блоки могут оказаться полезными, если вы захотите разделить большие по объему двоичные файлы на менее объемные модульные единицы (это может пригодиться для сценариев удаленной загрузки). Следующим нашим шагом будет формализация понятия приватного компоновочного блока.

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

Компоновочные блоки, которые создавались вами в этой главе до сих пор, инсталлировались, как приватные компоновочные блоки. Приватные компоновочные блоки должны размещаться в том же каталоге, что и приложение-клиент (такой каталог называется каталогом приложения) или в его подкаталоге. Напомним, что результатом добавления ссылки на CarLibrary.dll при построении приложений CSharpCarClient.exe и VbNetCarClient.exe в Visual Studio 2005 было копирование CarLibrary.dll в каталог приложения-клиента.

Когда программа-клиент использует типы, определенные в этом внешнем компоновочном блоке, среда CLR просто загружает локальную копию CarLibrary.dll. Ввиду того, что среда выполнения .NET не использует реестр системы при поиске компоновочных блоков, вы можете переместить компоновочные блоки CSharpCarClient.exe (или VbNetCarClient.exe) вместе c CarLibrary.dll в другое место на своей машине и успешно запустить приложение.

Деинсталляция (a также тиражирование) приложения, использующего исключительно приватные компоновочные блоки, не требует особых усилий: нужно просто удалить (или скопировать) папку приложения. В отличие от COM-приложений, здесь не нужно беспокоиться о десятках "осиротевших" параметров, разделов и ветвей реестра. Но еще более важно то, что удаление приватных компоновочных блоков никак не влияет на работоспособность других приложений, установленных на машине.

Полный идентификатор приватного компоновочного блока состоит из понятного имени компоновочного блока и числового номера его версии, которые должны быть записаны в манифест компоновочного блока. Понятное имя (friendly name) – это просто имя модуля, содержащего манифест компоновочного блока, без файлового раcширения. Так, если вы проверите манифест компоновочного блока CarLibrary.dll, то обнаружите там следующее (ваша версия будет, скорее всего, другой).

.assembly.CarLibrary {

 …

 .ver 1:0:454:30104

}

Ввиду изолированной природы приватного компоновочного блока, имеет смысл то, что среда CLR не использует номер версии при выяснении места размещения такого компоновочного блока. Предполагается, что для приватных компоновочных блоков не обязательно выполнять проверку версии, поскольку приложение-клиент является единственным приложением, "знающим" об их существовании. Поэтому вполне вероятно, что на одной машине будет много копий одного и того же приватного компоновочного блока в разных каталогах приложений.

Среда выполнения .NET выясняет место размещения приватного компоновочного блока с помощью технологий зондирования, которые на самом деле оказываются намного менее агрессивными, чем кажется из названия. Зондирование представляет собой процесс отображения запроса внешнего компоновочного блока в соответствующее место размещения запрошенного двоичного файла, Запрос на загрузку компоновочного блока может быть либо неявным, либо явным. Неявный запрос выполняется тогда, когда среда CLR использует манифест для выяснения места расположения компоновочного блока, определенного с помощью лексемы .assembly extern.

// Неявный запрос загрузки.

.assembly extern CarLibrary

{…}

Явный запрос загрузки происходит при использовании в программе метода Load() или LoadFrom() типа System.Reflection.Assembly, обычно с целью динамического связывания и динамического вызова членов запрашиваемого типа. Мы рассмотрим эти темы позже в главе 12, а сейчас только приведем пример явного запроса загрузки в следующем фрагменте программного кода.

// Явный запрос загрузки.

Assembly asm = Assembly.Load("CarLibrary");

В любом из этих случаев среда CLR извлекает понятное имя компоновочного блока и начинает зондирование каталога приложения-клиента в поисках файла с именем CarLibrary.dll. Если этот файл не обнаружен, делается попытка найти выполняемый компоновочный блок с тем же понятным именем (CarLibrary.exe). Если ни одного из указанных файлов в каталоге приложения не обнаруживается, среда выполнения прекращает попытки и генерирует исключение FileNotFound.

Замечание. Если запрошенного компоновочного блока в каталоге приложения-клиента нет, среда CLR пытается проверить подкаталог клиента с именем, соответствующим понятному имени запрошенного компоновочного блока (скажем, C:\MyClient\CarLibrary). Если запрошенный компоновочный блок обнаружится в таком подкаталоге, среда CLR загрузит найденный компоновочный блок в память.

Конечно, можно инсталлировать .NET-приложение с помощью простого копирования всех требуемых компоновочных блоков в одну папку на жестком диске пользователя, но вы, скорее всего, предпочтете определить ряд подкаталогов для группировки взаимосвязанного содержимого. Предположим, например, что у вас есть каталог приложения C:\MyApp, содержащий CSharpCarClient.exe. В этом каталоге может быть подкаталог с именем MyLibraries, который содержит CarLibrary.dll.

Несмотря на предполагаемую связь между этими двумя каталогами, среда CLR не будет зондировать подкаталог MyLibraries, если вы не создадите файл конфигурации с соответствующим требованием. Файлы конфигурации состоят из XML-элементов, позволяющих влиять на процесс зондирования. "По закону" файлы конфигурации должны иметь то же имя, что и соответствующе приложение, но иметь расширение *.config, и должны размещаться в каталоге приложения-клиента. Так, если вы хотите создать файл конфигурации для CSharpCarClient.exe, он должен называться CSharpCarClient.exe.config.

Для иллюстрации создайте новый каталог на вашем диске C, назвав его MyApp (например, с помощью Windows Explorer). Затем скопируйте CSharpCarClient.exe и CarLibrary.dll в этот новый каталог и запустите программу на выполнение с помощью двойного щелчка на ее файле. Ваша программа должна выполниться успешно (вспомните о том, что компоновочные блоки не требуют регистрации!). Теперь создайте в C:\MyApp подкаталог, выбрав для него название MyLibraries (рис. 11.11), и переместите в него CarLibrary.dll.

Рис. 11.11. Теперь CarLibrary.dll размещается в подкаталоге MyLibraries

Попытайтесь выполнить программу снова. Ввиду того, что среда CLR не сможет найти "CarLibrary" непосредственно в каталоге приложения, вы получите необработанное исключение FileNotFound (файл не найден).

Чтобы выправить ситуацию создайте новый файл конфигурации CSharpCarClient.exе.config и сохраните его в папке, содержащей приложение CSharpCarClient.exe (в данном случае это папка C:\MyApp). Откройте cозданный файл и введите в него следующий код в точности так, как показано ниже (язык XML является чувствительным к регистру символов).

<configuration>

 ‹runtime›

  ‹assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"›

   ‹probing privatePath="MyLibraries"/›

  ‹/assemblyBinding›

 ‹/runtime›

‹/configuration›

Файлы *.config .NET всегда начинаются корневым элементом ‹configuration›. Вложенный в него элемент ‹runtime› может содержать элемент ‹assemblyBinding›, который, в свою очередь, может содержать вложенный элемент ‹probing›. Для данного примера наиболее важным является атрибут privatePath, поскольку он используется для указания подкаталогов в каталоге приложения, где среда CLR должна осуществлять зондирование.