Российский Государственный Технологический Университет им. К.Э. Циолковского
Опубликован: 02.03.2007 | Доступ: свободный | Студентов: 5678 / 802 | Оценка: 3.96 / 3.45 | Длительность: 27:04:00
ISBN: 978-5-9556-0086-4
Лекция 10:

Атрибуты, сборки, рефлексия

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

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

Версию можно "подсмотреть" в манифесте сборки с помощью 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 description for Class1.
    
    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\Shared Assembly00\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.

Сборка – там!

kewezok kewezok
kewezok kewezok
Елена Шляхт
Елена Шляхт
Объясните плиз в чем отличие а++ от ++а
Почему результат разный?
int a=0, b=0;
Console.WriteLine(a++); //0
Console.WriteLine(++b); //1
a++;
++b;
Console.WriteLine(a); //2
Console.WriteLine(b); //2