После компиляции манифест сборки будет содержать запись открытого ключа. Фактически в нем будет выделено место и для секретного ключа, поэтому повторное подписание сборки не приведет к каким-либо изменениям в ней (за исключением записи нескольких дополнительных байтов в манифесте). Попытка отладки сборки приведет к отображению сообщения об ошибке, показанного на рис. 30.8.

MKrosoh Visu&l Studto

Error while trymg to run project Could not load file or ajjembly Dele,Sign. Version=lJOOO Cultures neutral

PublicKeyToken=aladla5619382d41 or one of rti dependencies Strong name validation failed (bception from HRESULT: 0x6013141 A)

Puc. 30.8. Сообщение об ошибке

Это обусловлено тем, что по умолчанию исполняющая среда .NET будет загружать только неподписанные сборки (не имеющие определенного файла ключа) либо запускать только полностью подписанные сборки, содержащие и открытые, и секретные ключи. По существу .NET не допускает загрузку частично подписанных сборок, что и служит причиной отображения сообщения об ошибке, показанного на рис. 30.8. В разделе, следующем за посвященным регистрации сборки в GAC, показано, как разрешить загрузку частично подписанных сборок, используя процесс пропуска подтверждения подлинности.

Регистрация в GAC

Попытка использования утилиты Gacutil (доступной также в .NET 2.0 Framework SDK) для регистрации частично подписанной сборки в GAC ведет к отображению сообщения об ошибке, подобного следующему:

Microsoft (R) .NET Global Assembly Cache Utility. Version 3.5.20706.1 Copyright (C) Microsoft Corporation. All rights reserved.

Failure adding assembly to the cache: Strong name signature could not be verified. Was the assembly built delay-signed?

Ошибка добавления сборки в кеш: Не удалось проверить подлинность подписи строгого имени. Не было ли отложено подписание сборки?

На данный момент сборка подписана только частично, а по умолчанию GAC и Visual Studio .NET будут принимать сборки только со строгим именем. Однако с помощью утилиты sn из .NET можно потребовать пропуск проверки надежности строгого имени сборки, снабженной отложенной подписью. Помните ранее полученный маркер открытого ключа? Именно теперь он вступает в дело:

> sn -Vr *,aladla5619382d41

Эта команда разрешает каркасу .NET регистрировать в GAC любые сборки, снабженные маркером открытого ключа aladla5619382d41, и, что еще важнее для данного примера, позволяет запускать DelaySign.exe из среды Visual Studio. Ввод приведенного кода в командной строке генерирует следующее сообщение:

Microsoft (R) .NET Framework Strong Name Utility Version 3.5.20706.1 Copyright (C) Microsoft Corporation. All rights reserved.

Verification entry added for assembly *, aladla5619382d41

Запись подтверждения подлинности добавлена для сборки *,aladla5619382d41

Теперь попытка установки сборки в GAC с помощью утилиты Gacutil завершается успешно. Добавляя запись проверки подлинности для сборки, не обязательно применять значение открытого ключа - с помощью следующей команды можно было бы указать возможность регистрации всех сборок:

> sn -Vr *

Или же можно определить конкретную сборку, вводя ее полное имя, подобно следующему:

> sn -Vr DelaySign.exe

Эти данные постоянно хранятся в так называемой таблице пропуска проверки подлинности, представляющей собой файл на диске. Для получения списка всех записей таблицы пропуска проверки подлинности введите следующую команду (команды чувствительны к регистру):

> sn -VI

В результате на экран компьютера будет выведена следующая информация:

Microsoft (R) .NET Framework Strong Name Utility Version 3.5.20706.1 Copyright (C) Microsoft Corporation. All rights reserved.

Assembly/Strong Name Users

*,aladla5619382d41 All users

Обратите внимание на столбец Users (Пользователи) - в нем можно определить, что данная сборка может загружаться в GAC поднабором из всех пользователей. Для получения дополнительных сведений по этой и другим возможностям именования сборок обратитесь к документации утилиты sn. ехе.

Завершение строгого имени

Последний этап процесса - это компиляция открытого и секретного ключей в сборку; сборку, снабженную обеими записями, называют обладающей строгим именем, и она может быть зарегистрирована в GAC без использования записи пропуска проверки подлинности.

Снова используйте утилиту sn.exe, на этот раз с переключателем -R. Переключатель -R означает, что мы собираемся заново подписать сборку и добавить часть секретного ключа:

> sn -R delaysign.dll Company.snk

В результате отображается следующее:

Microsoft (R) .NET Framework Strong Name Utility Version 3.5.20706.1 Copyright (C) Microsoft Corporation. All rights reserved.

Assembly delaysign.dll successfully re-signed Сборка delaysign.dll успешно подписана заново

Остальные параметры, следующие за ключом -R - имя сборки, которая должна быть заново подписана, и файл ключа, содержащий открытый и секретный ключи.

Пользовательские атрибуты

До сих пор мы уделяли внимание некоторым атрибутам, входящим в состав .NET Framework. Однако доступные возможности не ограничиваются ими - можно создавать также собственные атрибуты.

В этом разделе в качестве примера пользовательского атрибута мы создадим атрибут BugFixAttribute, который можно применять для записи в исходный код информации о том, кто внес изменения в данную область функциональных возможностей.

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

□ Пользовательский атрибут должен быть производным от System. Attribute.

□ Конструктор (конструкторы) атрибута могут содержать только те типы, которые могут быть подставлены во время компиляции - такие как строки и целочисленные типы.

Ограничения, налагаемые на типы параметров конструкторов атрибутов, обусловлены способом хранения атрибутов в метаданных сборки. При использовании атрибута внутри кода конструктор атрибута применяется внутри его текста, как показано в следующей строке кода:

[assembly: AssemblyKeyFile ( CompanyPublic.snk ) ]

В метаданных сборки этот атрибут присутствует в виде инструкции по вызову конструктора AssemblyKeyFileAttribute, который принимает строку. В предыдущем примере эта строка - CompanyPublic. snk. Определение пользовательского атрибута означает, что пользователи атрибута в основном записывают параметры в конструктор класса.

BugFixAttribute

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

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

Полный исходный код этого примера доступен в каталоге Chapters О/07 BugFix.

Чтобы создать класс пользовательского атрибута, необходимо выполнить перечисленные ниже действия.

□ Создать класс, производный от System. Attribute.

□ Создать необходимые конструктор (конструкторы) и общедоступные свойства.

а Снабдить класс атрибутом, определяющим, где можно применять пользовательский атрибут.

Все эти шаги рассматриваются в последующих разделах.

Создание класса пользовательского атрибута

Этот шаг самый простой. Для его выполнения достаточно создать класс, производный от System.Attribute:

public class BugFixAttribute : Attribute