Построение сборки, ссылающейся
на сборку со строгим именем
Какую бы сборку вы ни строили, в результате всегда получается сборка, ссы-
лающаяся на другие сборки со строгими именами. Это утверждение верно хотя
бы потому, что класс
System.Object
определен в
MSCorLib dll
, сборке со строгим
именем. Однако велика вероятность того, что сборка также будет ссылаться на
типы из других сборок со строгими именами, изданными Microsoft, сторонними
105
Построение.сборки,.ссылающейся.на.сборку.со.строгим.именем
разработчиками либо созданными в вашей организации. В главе 2 показано, как
использовать компилятор
CSC exe
с параметром
/reference
для определения
сборки, на которую должна ссылаться создаваемая сборка. Если вместе с именем
файла задать полный путь к нему,
CSC exe
загрузит указанный файл и использует
его метаданные для построения сборки. Как отмечено в главе 2, если задано имя
файла без указания пути,
CSC exe
пытается найти нужную сборку в следующих
каталогах (просматривая их в порядке перечисления).
1. Рабочий каталог.
2. Каталог, где находится файл
CSC exe
. Этот каталог также содержит DLL-
библиотеки CLR.
3. Каталоги, заданные параметром
/lib
командной строки компилятора.
4. Каталоги, указанные в переменной окружения
LIB
.
Таким образом, чтобы скомпоновать сборку, ссылающуюся на файл
System
Drawing dll
разработки Microsoft, при вызове
CSC exe
можно задать параметр
/reference:System.Drawing.dll
. Компилятор проверит перечисленные ка-
талоги и обнаружит файл
System Drawing dll
в одном каталоге с файлом
CSC
exe.
— том же, который содержит библиотеки DLL версии CLR, которую сам
использует для создания сборки. Однако несмотря на то, что при компиляции
сборка находится в этом каталоге, во время выполнения эта сборка загружается
из другого каталога.
Дело в том, что во время установки .NET Framework все файлы сборок, создан-
ных Microsoft, устанавливаются в двух экземплярах. Один набор файлов заносится
в один каталог с CLR, а другой — в каталог GAC. Файлы в каталоге CLR облегчают
построение пользовательских сборок, а их копии в GAC предназначены для загрузки
во время выполнения.
CSC exe
не ищет нужные для компоновки сборки в GAC, потому что для этого
вам пришлось бы задавать путь к файлу сборки, а структура GAC не документи-
рована. Также можно было бы задавать сборки при помощи не менее длинной, но
чуть более изящной строки вида:
System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken= b03f5f7f11d50a3a
Оба способа были настолько неуклюжими, что было решено предпочесть им
установку на пользовательский жесткий диск двух копий файлов сборок.
Кроме того, сборки в каталоге CLR не привязаны к машине. Иначе говоря, эти
сборки содержат только метаданные. Так как код IL не нужен на стадии построения,
в этом каталоге не нужно хранить версии сборки для x86, x64 и ARM. Сборки в GAC
содержат метаданные и IL, потому что код нужен только во время выполнения.
А поскольку код может оптимизироваться для конкретной архитектуры процессора,
в GAC могут храниться несколько версий одной сборки; они находятся в разных
подкаталогах, соответствующих разным архитектурам процессоров.
Do'stlaringiz bilan baham: |