C# для профессионалов. Том II, Ватсон Карли

C# для профессионалов. Том II

на обложку

Ватсон Карли

Шрифт:

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 полагается на элемент

, связанный с упомянутыми выше конфигурационными файлами. Если такой элемент не предоставлен, то CLR ищет файл (называемый 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 не представлена в данном приложении.

Все сборки в глобальном кэше сборок должны иметь устойчивое имя. Глобальный кэш сборок применяется для хранения сборок, специально созданных для общего использования несколькими приложениями на машине. Существует несколько способов размещения сборки в глобальном кэше сборок. Можно использовать программу установки, созданную для работы с глобальным кэшем сборок, .NET Framework SDK предоставляет программу установки с именем

gacutil.exe

. Чтобы поместить

FirstLibrary.dll

в глобальный кэш сборок, воспользуйтесь командой:

gacutil -i FirstLibrary.dll

Можно использовать Проводник Windows для перетаскивания сборок в кэш. Отметим, что необходимо иметь привилегии администратора на машине, чтобы устанавливать сборки в глобальный кэш сборок, независимо от используемого подхода.

Типы данных

Типы данных в Java и в C# можно сгруппировать в две основные категории: типы данных значений и ссылочные типы. Существует только одна категория типа данных значений в Java. Все типы данных значений являются по умолчанию примитивными типами данных языка. C# предлагает более обильный ассортимент. Типы данных значений можно разбить на три основные категории: