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

Пользователей многомодульного компоновочного блока не должно заботить то, что компоновочный блок, на который они ссылаются, состоит из нескольких модулей. Чтобы пояснить ситуацию, мы построим новое приложение-клиент Visual Basic .NET с командной строки. Создайте новый файл Client.vb, содержащий приведенное ниже определение. Сохраните его в там месте, где находится ваш многомодульный компоновочный блок.

Imports AirVehicles

Module Module1

Sub Main()

Dim h As New AirVehicles.Helicopter()

h.Takeoff()

' Это загрузит *.netmodule по требованию.

Dim u As New UFO()

u.AbductHuman()

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 {

…

. ver1: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 загрузит найденный компоновочный блок в память.