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

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

Процедура отложенной подписи начинается правомочным лицом, имеющим доступ к файлу *.snk, с извлечения из этого файла значения открытого ключа. Для этого используется sn.exe с опцией -р, позволяющей создать новый файл, содержащий значение открытого ключа.

sn -p myKey.snk testPublicKey.snk

Файл testPublicKey.snk можно предоставить всем разработчикам для создания и проверки строго именованных компоновочных блоков. Чтобы сообщить компилятору C# о том, что соответствующий компоновочный блок должен использовать процедуру отложенной подписи, разработчик должен установить для атрибута AssemblyDelaySign значение true (истина), а также указать файл с псевдоключом, как параметр атрибута AssemblyKeyFile. Ниже показаны строки, которые следует ввести в файл AssemblyInfo.cs проекта.

[assembly: AssemblyDelaySign(true)]

[assembly: AssemblyKeyFile(@"C:\MyKey\ testPublicKey.snk)]

Замечание.При использовании Visual Studio 2005 те же атрибуты можно создать "визуально", используя возможности, предлагаемые на странице свойств проекта.

После разрешения отложенной подписи для компоновочного блока следующим шагом является отключение процесса проверки подписи, который для компоновочных блоков, установленных в GAC, выполняется автоматически. Чтобы пропустить процесс проверки подписи на текущей машине, укажите (для sn.exe) опцию -vr.

sn.exe -vr MyAssembly.dll

По завершении тестирования компоновочный блок можно отправить уполномоченному объекту, имеющему доступ к настоящему файлу с открытым и секретным ключами, чтобы обеспечить двоичному файлу настоящую цифровую подпись. Здесь снова необходимое решение обеспечивает sn.exe, на этот раз при использовании флата -r.

sn.exe -r MyAssembly.dll C:\MyKey\myKey.snk

Чтобы в заключение активизировать процесс проверки подписи, применяется флаг -vu.

sn.exe -vu MyAssembly.dll

Конечно, если вы (или ваша компания) создаете компоновочные блоки только дан внутреннего использования, вам процедура отложенной подписи может никогда не понадобиться. Но если вы создаете компоновочные блоки .NET для внешних потребителей, возможность отложенной подписи позволяет обеспечить безопасность с разумными ограничениями для всех заинтересованных сторон.

При построении приложений, использующих общедоступные компоновочные блоки, единственное отличие от случая использования приватного компоновочного блока заключается в том, как вы ссылаетесь на соответствующую библиотеку в Visual Studio 2005. Фактически с точки зрения используемого инструмента никакой разницы нет (вы все равно используете диалоговое окно Add Reference). Важно понять то, что это диалоговое окно не позволит вам сослаться на компоновочный блок путем просмотра папки assembly. Попытки сделать это будут бесполезными – возможность сослаться на выделенный компоновочный блок предоставлена не будет (рис. 11.21).

Рис. 11.21. Неправильно! Visual Studio 2005 не позволяет сослаться на общедоступный компоновочный блок путем перехода в папку assembly

Вместо этого на вкладке Browse нужно перейти в каталог \Bin\Debug оригинального проекта (рис. 11.22).

Рис. 11.22. Правильно! В Visual Studio 2005 для ссылки на общедоступный компоновочный блок нужно перейти в каталог \Bin\Debug соответствующего проекта

Учитывая этот (раздражающий) факт, создайте новое консольное приложение C# с именем SharedCarLibClient и проверьте возможность использования своих типов.

using CarLibrary;

namespace.SharedCarLibClient {

class Program {

static void Main(string[] args) {

SportsCar c = new SportsCar();

Console.ReadLine();

}

}

}

После компиляции приложения-клиента, в программе Проводник Windows перейдите в каталог, содержащий файл SharedCarLibClient.exe, и убедитесь в том, что Visual Studio 2006 не скопировала CarLibrary.dll в каталог приложения-клиента. При ссылке на компоновочный блок, манифест которого содержит значение .publickey, Visual Studio 2005 предполагает, что строго именованный компоновочный блок, вероятнее всего, установлен в структуре GAC и поэтому не "утруждает" себя копированием двоичного файла.

Pиc. 11.23. С помощью свойства Copy Local можно "заставить" систему выполнить копирование строго именованной библиотеки программного кода

В качестве краткого замечания укажем на то, что можно "заставить" Visual Studio 2005 скопировать общедоступный компоновочный блок в каталог клиента. Для этого нужно выбрать компоновочный блок из узла References в окне Solution Explorer, а затем в окне Properties (рис. 11.23) установить для свойства Copy Local (копировать в локальную папку) значение True (истина) вместо значения False (ложь).

Напомним, что при генерировании строгого имени компоновочного блока в манифест компоновочного блока записывается значение открытого ключа. Точно так же, когда клиент ссылается на строго именованный компоновочный блок, в его манифест записывается "конденсированное" хешированное значение открытого ключа, обозначенное лексемой .publickey. Если с помощью ildasm.exe открыть манифест SharedCarLibClient.exe, вы увидите там следующее.

.assembly extern CarLibrary {

.publickeytoken = (21 9E F3 80 C9 34 8A 38)

.ver 1:0:0:0

}

Если сравнить код открытого ключа, записанный в манифесте клиента со значением для открытого ключа, показанным структурой GAC, вы обнаружите полное совпадение. Напомним, что открытый ключ является одной из составляющих строгого имени, идентифицирующего компоновочный блок. С учетом этого среда CLR загрузит только версию 1.0.0.0 компоновочного блока CarLibrary, открытый ключ которого имеет хешированное значение 219EF380C9348A38. Если среда CLR не найдет компоновочный блок, имеющий такое описание в рамках GAC (и не найдет приватного компоновочного блока с именем CarLibrary в каталоге клиента), то будет сгенерировано исключение FileNotFound (файл не найден).