C# предоставляет совсем другие механизмы для упаковки классов в библиотеку. По умолчанию все файлы C# в проекте станут частью единицы компиляции при использовании VS.NET. Если применяется командная строка, необходимо будет явно добавлять каждый файл, который должен быть частью единицы компиляции, как описано выше.
Библиотеки кодов компилируются в РЕ (portable executable — переносимый исполнимый) тип файла. Необходимо в этом месте сделать различие между библиотеками кодов, о которых идет речь, и проектом Class Library в C#, который может создаваться с помощью IDE VS.NET. Под библиотекой кода понимается повторно используемое множество файлов C#, соединенных вместе в некоторой единице компиляции, поэтому происходит ссылка на файл РЕ, а не на реальную DLL или ЕХЕ. Библиотека кода такого вида более часто называется сборкой, поэтому это название будем использовать в дальнейшем, чтобы избежать путаницы.
Так же как файл JAR, сборка имеет манифест, который описывает ее содержимое. Манифест сборки C# делает, однако, значительно больше. Он содержит все метаданные (совокупность данных, описывающая, как связаны элементы сборки), необходимые для определения требований версии, идентичности безопасности и всей информации, служащей для определения области действия сборки и разрешения ссылок на ресурсы и классы. Манифест сборки может храниться либо в файле РЕ (ЕХЕ или DLL) с кодом IL, либо как автономный файл, который содержит только данные манифеста сборки. В .NET пространства имен, содержащиеся внутри сборки, представлены внешнему миру (то есть, любым потребителям сборки, таким, как другие сборки) с помощью информации метаданных о типах, хранящейся в манифесте сборки.
Классы в namespace_samples.cs могут компилироваться в библиотеку с помощью команды:
CSC /target:library /out:FirstLibrary.dll namespace_samples.cs
Чтобы сделать информацию о типах из одной сборки доступной для других сборок, можно использовать два ключа компилятора: /addmodule и /reference. Они являются по сути одинаковыми, за исключением того, что /reference предназначен для сборок с манифестом сборки, в то время как /addmodule предназначен для сборок без манифеста сборки (модуль не имеет манифеста сборки). Синтаксис для добавления внешних ссылок из командной строки будет следующим:
csc /reference: <lib.dll>; <libn.cs> <filename.exe>
или:
csc /addmodule: <lib.dll>; <libn.cs> <filename.exe>
Чтобы добиться этого с помощью VS.NET, сделайте щелчок правой кнопкой мыши на папке References своего проекта в Solution Explorer и выберите Add Reference. Появится диалоговое окно, содержащее ряд доступных ссылок и позволяющее просматривать файловую систему в поисках ссылок. Можно также вызвать это диалоговое окно, выбирая пункт Add Reference из меню Project, когда выделен требуемый проект. Добавление ссылки в текущую сборку обычно копирует упомянутый файл в папку проекта, где будет располагаться новая сборка.
Давайте создадим теперь потребителя для библиотеки AddLib, который аналогичен по форме и функциональности созданному ранее классу JavaFrame:
// LibConsumer.cs
namespace Com.CSapp {
using System;
using System.Windows.Forms;
using Com.CsLib;
public class Form1 : System.Windows.Forms.Form {
public Form1() {
AddLib al = new AddLib();
this.Text = "C# Form version " + al.operationAdd(12, 23);
}
public override void Dispose() {
base.Dispose();
}
Static void Main(string[] args) {
Form1 f1 = new Form1();
Application.Run(f1);
}
}
}
Этот код можно компилировать из командной строки со ссылкой на FirstLibrary.dll, введя следующую команду:
csc /reference: FirstLibrary.dll /target:exe /out:EmptyForm.exe LibConsumer.cs
Используя VS.NET, надо сначала сослаться на FirstLibrary.dll, как описано ранее, и затем собрать приложение. Когда приложение будет успешно собрано, выполните его. Оно должно создать форму Windows с заголовком C# form Version 35.
Обнаружение и разрешение
Мы уже обсудили, как JRE разрешает ссылки на другие классы, используя загрузчик классов для проверки во время выполнения переменной окружения Classpath. CLR проходит также ряд шагов, часто называемых зондированием (probing), при попытке найти сборку и разрешить ссылку на сборку. Попытка выполнить EmptyForm.exe приводит в движение ряд вещей. По умолчанию весь управляемый код загружается в домен приложения и обрабатывается определенным потоком выполнения операционной системы. Указанные сборки, означающие, что их типы используются в коде домена приложения, также должны загружаться, прежде чем их можно будет выполнить. CLR проходит несколько стадий, чтобы обнаружить и связаться с указанной сборкой.
Так как поведение по соединению со сборками может конфигурироваться на основе конфигурационных файла приложения, файла издателя и файла машины/администратора, CLR должна брать эту конфигурационную информацию, чтобы обеспечить извлечение соответствующей версии указанной сборки. Все эти файлы основаны на XML и следуют похожему синтаксису. Они предоставляют такую информацию, как перенаправление связывания, расположение кода и режимы связывания для определенных сборок. Обычно правильная версия сборки определяется некоторой комбинацией трех конфигурационных файлов и собственным манифестом сборки.
CLR сначала проверяет, не переопределяет ли информация конфигурационного файла приложения информацию, которая хранится в манифесте вызывающей сборки. Затем CLR проверяет конфигурационный файл издателя. Этот файл присутствует, только когда приложение было обновлено новыми версиями одного или нескольких компонентов приложения. Это прежде всего используется для переопределения информации в конфигурационном файле приложения, чтобы приложение выбрало новую версию компонента. CLR затем проверяет конфигурационный файл машины/администратора. Хотя он просматривается последним, настройки, присутствующие в этом файле, получают приоритет по отношению ко всем другим конфигурационным настройкам. По сути администраторы используют admin.cfg, чтобы определить ограничения связывания, локальные для данной машины.
Затем CLR необходимо найти сборку. В Java JRE будет действовать в текущем каталоге и в classpass, чтобы найти класс, необходимый для разрешения ссылки. В определении расположения заданной сборки CLR полагается на элемент <codeBase>, связанный с упомянутыми выше конфигурационными файлами. Если такой элемент не предоставлен, то CLR ищет файл (называемый probing) в корневом каталоге приложения, во всех каталогах, перечисленных в конфигурационных файлах элемента <probing> и во всех подкаталогах корня приложения, которые имеют такое же имя, как и зондируемая сборка. Эти элементы всегда определяются относительно корневого каталога приложения. Отметим, что CLR всегда ищет имя сборки, соединенное с двумя допустимыми расширениями файлов РЕ — .exe и .dll.
Наконец, если ссылка сделана на сборку с устойчивым именем, CLR будет искать в глобальном кэше сборок. Устойчивые имена и глобальный кэш сборок мы рассмотрим более подробно в следующем разделе.
Строгие имена и глобальный кэш
Устойчивое (строгое) имя делает сборку глобально уникальной. Оно состоит из идентификатора сборки, открытого ключа и цифровой подписи. Так как сборка, созданная с одним открытым ключом имеет другое имя, чем сборка, созданная с другим открытым ключом, то уникальность имени сборки гарантирована. Нельзя изменить сборку с устойчивым именем, не имея доступа к открытому ключу, использованному при ее создании, следовательно, устойчивое имя гарантирует, что никто не сможет создать другие версии этой сборки. Устойчивые имена предоставляют также жесткий контроль целостности. Создание устойчивого имени является двухшаговым процессом. Сначала необходимо создать или иметь ключевую пару. Создание ключевой пары можно выполнить в командной строке с помощью команды:
sn -k <имя файла ключа>
Например, чтобы создать файл ключа examplekey.key, надо ввести:
sn -k examplekey.key
После создания файл ключа используется для присвоения устойчивого имени сборке двумя способами. Из командной строки можно использовать утилиту alink следующим образом:
al /keyfile: <имя файла ключа> <имя сборки>
Чтобы задать для FirstLibrary.dll строгое имя, можно выполнить:
al /keyfile:examplekey.key FiretLibrary.dll
или в VS.NET изменить атрибут [assembly: AssemblyKeyFile("")] в файле AssemblyInfo.cs. Замените просто пустую строку на строку, представляющую имя файла ключа. Сборку FirstLibrary.dll можно затем ассоциировать с ключом, меняя атрибут AssemblyKeyFile на [assembly: AssemblyKeyFile("examplekey.key")]. Какой бы метод ни использовался, конечный результат получается тот же самый. CLR будет устанавливать ключ в файл с помощью Crypto Service Provider (CSP). Работа CSP не представлена в данном приложении.
