Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Методичка для КР по ООП.doc
Скачиваний:
8
Добавлен:
18.04.2019
Размер:
2.47 Mб
Скачать

Версия сборки

Эта характеристика имеется у каждой сборки, несмотря на то, что частной сборке она и ни к чему.

Версию можно “подсмотреть” подсмотрели в манифесте сборки с помощью IlDasm.exe. Можно было бы для пущей крутизны кода поле Version проинициализировать непосредственно (дело хозяйское):

И тут открываются несколько приколов:

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

  • Если сборка уникальна и среда разработки приложения ничего не знает о других версиях данной сборки - в поле Version можно спокойно забивать любые четвёрки чисел. Лишь бы требования формата были соблюдены.

  • Две одноименных частные сборки с разными версиями в раздел References третьей сборки загрузить не получается. Одноимённые файлы с одинаковым расширением в один каталог не помещаются. Не взирая на версии.

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

Используется блок try, поскольку загружаемую сборку можно и не найти.

При загрузке сборки известно её расположение (application directory), однако с расширением имени могут возникнуть проблемы. Действует такой алгоритм “поиска” (и называть-то это поиском как-то не удобно):

Среда выполнения .NET пытается обнаружить файл с расширением .dll.

В случае неудачи среда выполнения .NET пытается обнаружить файл с расширением .exe.

В случае неудачи – предпринимаются ДРУГИЕ алгоритмы поиска.

Файл конфигурации приложения

Так что за ДРУГИЕ-такие алгоритмы?

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

Файл конфигурации – это текстовый файл со странным именем <ИмяФайла.Расширение>.config, в котором размещаются в строго определённом порядке теги, прописанные на языке XML.

Среда выполнения .NET умеет читать XML.

Утверждается, что если расположить частные сборки в других подкаталогах приложения, нежели bin\Debug, то с помощью файла конфигурации эти сборки исполняющая среда БЕЗ ТРУДА обнаружит. Однако не находит. Может быть, чего криво делаю?

Файл AssemblyStarter.exe.config:

<configuration>

<runtime>

<assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1” >

<probing privatePath=”XXX\YYY”/>

</assemblyBinding>

</runtime>

</configuration>

Общедоступная сборка

Строгое имя общедоступной сборки стоит из:

  • дружественного текстового имени и “культурной” информации,

  • идентификатора версии,

  • пары Открытый/Закрытый ключ,

  • цифровой подписи

Делаем общую сборку

1. Сначала – ЧАСТНАЯ сборка.

using System;

namespace SharedAssembly00

{

/// <summary>

/// Summary description for Class1.

/// </summary>

public class Class1

{

public Class1()

{

}

public void f0()

{

Console.WriteLine(“This is SharedAssembly00.f0()”);

}

}

}

2. Делаем пару Открытый/Закрытый ключ

Для чего в Visual Studio .NET 2003 Command Prompt командной строкой вызываем утилиту-генератор ключей

D:\...>sn –k theKey.cnk

3. В файле сборки AssemblyInfo.cs (таковой имеется в каждом проекте, ранее не использовался) дописываем в качестве значения ранее пустого атрибута AssemblyKeyFile полный путь к созданному утилитой sn файлу (в одну строчку):

[assembly: AssemblyKeyFile(@”D:\Users\WORK\Cs\AssemblyTest\SharedAssembly00\theKey.snk”)]

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

Клиентское приложение

Сборка общего пользования, установленная в GAC

В манифесте клиента имеется ссылка на внешнюю сборку общего пользования. Маркер открытого ключа этой сборки отмечен тегом :

::::::::::

.assembly extern SharedAssembly00

{

.publickeytoken =

(90 8E D8 5E 3E 37 72 08 ) // ...^>7r.

.ver 1:0:1790:37888

}

::::::::::

Манифест сборки общего пользования в GAC содержит такое же значение ключа:

908ED85E3E377208

Его можно увидеть при исследовании содержимого GAC (свойства элемента)

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

5. Размещаем общедоступную сборку в GAC. Для чего либо используем утилиту gacutil.exe с ключом \i и именем сборки с полным путём в качестве второго параметра. Либо просто перетаскиваем мышкой файл сборки в каталог, содержащий GAC. В случае успеха наблюдаем состояние GAC.

Сборка там!