Загальні складки і GAC

Загальні складки .NET зберігаються в глобальному кеші складок (GAC). Наявність глобального кеша економить дисковий простір і пам'ять, оскільки на стадії виконання програми на диску або в пам'яті досить зберігати лише один екземпляр збірки. Звичайно, при сумісному використанні складок виникають деякі проблеми, властиві старому механізму сумісного використання DLL на базі реєстру. На щастя, засоби контролю версії .NET дозволяють зберігати в GAC різні версії однієї збірки, тому кожне застосування може використовувати потрібну версію. Постарайтеся якомога рідше використовувати глобальний кеш складок і обмежитися наступними ситуаціями:

• якщо використання збірки в різних застосуваннях викликане абсолютною необхідністю, але з міркувань економії місця зберігання декількох локальних копій небажане;
  
• якщо збірка вимагає особливого рівня захисту (видалення складок з GAC дозволене тільки адміністраторові).
  

Список складок, що знаходяться в GAC, виводиться утилітою gacutil.exe з каталога \bin .NET SDK. Команда має наступний синтаксис: gacutil.exe -1

Нижче приведений початок списку для одного з наших комп'ютерів. Повний список має значні розміри; навіть на цій ранній стадії існування .NET він займає близько трьох сторінок:

Microsoft (R).NET Global Assembly Cache Utility.Version 1.0.2914.16

Copyright (C) Microsoft Corp,1998-2001,all rights reserved.

The Global Assembly Cache contains the following assemblies:

Accessibility.Version=1.0.2411.0,Culture=neutral,

Publickeytoken-b03f5f7flld50a3a,custom=null

Adodb,version=2. 7.0.0.culture-neutral

Publickeytoken-b03f5f7fild50a3a, Custom=null

Crvspackagelib.Version=1.0.0.0.Culture-neutral,

Publickeytoken=4f3430cff154c24c,custom=nul1

Crystal Deci si ons.Crystal

Reports.Engine.Version=9.1.0.0.Culture-neutral,

Publickeytoken=4f3430cff154c24c,custom=nul 1

Для загальних складок контроль версії грає набагато важливішу роль, ніж для закритих складок, тому в списку вказані номери версій кожної збірки. Останнє з Чотирьох чисел в номері версії визначає номер щоденної побудови, зміна якої вважається за непринципову. Далі слідує номер ревізії, зміна якого теж вважається за непринципову. Зміни наступних двох чисел (додаткового і основного номерів) принципові. Це означає, що якщо програма запрошує збірку версії 2.0.0.0, а в GAC знаходиться тільки версія 2.5.0.0, програма не працюватиме, якщо не внести спеціальні зміни до конфігураційного файлу. З іншого боку, версія 2.0.0.37 вважається за сумісну з версією 2.0.0.0 і успішно завантажується.

Всі складки, що включаються в GAC, повинні володіти сильними іменами. Це пов'язано з тим, що в GAC можуть зберігатися дві різні версії однієї збірки, які розрізняються по сильному імені.

Включення і видалення складок з GAC

Щоб загальна збірка автоматично включалася в GAC в процесі установки, найпростіше скористатися програмою установки з підтримкою GAC — наприклад, останньою версією пакету Microsoft Installer (MSI). Опис цієї програми виходить за рамки книги, але ми вкажемо, що цю програму можна безкоштовно завантажити з сайту MSDN (http://msdn.microsoft.com).

На стадії розробки замість програми установки зазвичай використовується утиліта

gacutil.exe. Синтаксис командного рядка:

gacutil -1 <імя_сборки>

Збірка із заданим ім'ям поміщається в GAC.

Сильні імена і сумісне використання складок

Сильні імена, як і GUID, мають бути унікальними у просторі та часі. На відміну від GUID, які теоретично можуть бути викрадені, сильні імена захищені від несанкціонованого використання за допомогою механізму шифрування з відкритим ключем [ За умови надійного зберігання закритого ключа. ]. Конкретні схеми шифрування бувають дуже складними, проте в цілому шифрування з відкритим ключем побудоване на досить простий ідеї — в деяких ситуаціях повернутися від кінцевого результату до початкових даних буває дуже, дуже складно. Наприклад, ви можете легко перемножити два цілі числа і отримати результат, але дізнатися початкові множники по твору неможливо — для цього потрібно знати хоч би один з них [ Цей принцип закладений в основу RSA, поширеного алгоритму шифрування з відкритим ключем. ].

Внутрішня реалізація виглядає таким чином: на підставі всієї інформа-циі, що міститься в збірці .NET обчислює хэш-код і застосовує до нього закритий ключ. Результатом є зашифрований хэш-код. Оскільки схема шифрування повинна забезпечувати можливість відновлення зашифрованих даних, зашифрований хэш-код розшифровується за допомогою відкритого ключа, при цьому виходить початковий хэш-код. На останньому кроці хэш-код наново обчислюється на підставі даних, що містяться в маніфесті, і два числа порівнюються. Якщо хэш-коды не збігаються, значить, збірка була модифікована, і .NET відмовляється завантажувати її.

У всіх схемах з відкритим ключем використовується пара ключів: відкритий і закритий. Відкритий ключ (public key) може вільно розповсюджуватися, оскільки без знання закритого ключа зашифроване повідомлення неможливо відновити за скільки-небудь прийнятний проміжок часу. Застосування закритого ключа до даних маніфесту дозволяє сертифікувати їх. Інші користувачі за допомогою відкритого ключа переконуються в тому, що збірка поступила саме від вас, а не із стороннього джерела. А в деяких випадках (наприклад, при використанні Verisign) вони навіть можуть переконатися в тому, що відкритий ключ належить саме вам, а не комусь іншому (шифрування з відкритим ключем захищає цілісність даних, але для перевірки відкритого ключа необхідні послуги третьої сторони).