Складки .NET, установка додатків і COM Interop

• Принципи роботи СОМ
• Складки .NET
• Маніфест
• Дослідження маніфесту
• Загальні складки і GAC
• Включення і видалення складок з GAC
• Сильні імена і сумісне використання складок
• Побудова ключів
• Сертифікація збірки
• COM Interop і виклики функцій DLL
• Виклики функцій DLL

На завершення ми вирішили зупинитися на проблемах установки і розміщення програм, а також на використанні готових програм, що використовують модель COM (Component Object Model). Взагалі-то на цю тему можна написати цілу книгу, але ми сподіваємося, що це короткий вступ допоможе вам перейти до самостійного вивчення цієї теми.

Установка більшості додатків .NET зводиться до простого копіювання каталога, що містить необхідні файли, на будь-який комп'ютер зі встановленим виконавчим середовищем .NET. Програма запускається подвійним клацанням на імені ЕХЕ-файла у вікні Провідника (Windows Explorer).

Вибираючи значок Setup and Deployment Project в діалоговому вікні New Project, ви дістанете доступ до вельми нетривіальних можливостей установки. Майстер Setup Wizard надзвичайно простий у використанні, але для більшості стандартних ситуацій його можливостей виявляється цілком достатньо.

Проте навіть в .NET іноді зустрічаються ситуації, коли просте копіювання не підходить, а програма-майстер дуже обмежує вашу свободу дій. Щоб знатися на принципах установки додатків .NET, необхідно знати, як працюють складки (assemblies), оскільки додатки .NET розповсюджуються у вигляді складок.

У багатьох встановлюваних застосуваннях хоч би частина роботи виконується традиційними об'єктами СОМ, тому в цьому розділі коротко торкнуться питання використання об'єктів СОМ в .NET [ І навпаки — об'єкти .NET можуть використовуватися в СОМ, проте ця можливість виглядає декілька екзотично. ]. А оскільки одній з цілей розробки .NET було виправлення недоліків СОМ, ми почнемо з короткого огляду СОМ і основних проблем, пов'язаних з цією технологією.

Принципи роботи СОМ

Технологія СОМ спрощує створення програм, що зберігають сумісність в різних версіях платформи Windows і більш менш незалежних від мови програмування. Компоненти СОМ можуть створюватися на різних мовах, включаючи класичний З (варіант для мазохістів), C++, Delphi, Vb5 і 6. Технологія СОМ з великим успіхом застосовувалася для створення об'єктів, призначених для вирішення спеціалізованих завдань, таких як елементи VB OCX.

Технологія СОМ була задумана як механізм, за допомогою якого програмні компоненти отримують інформацію про можливості інших компонентів і поводяться до них із запитами, не турбуючись про подробиці внутрішньої реалізації [ Існують і інші технології, орієнтовані на повторне використання програмної коди (наприклад, CORBA), але поки найбільшого успіху добилася саме модель СОМ. ]. Для цього був вироблений стандартний протокол отримання інформації про інтерфейси, підтримувані іншими компонентами, разом із стандартизацією засобів для звернення до конкретної реалізації інтерфейсу в екземплярах.

Проте у СОМ були свої недоліки. По-перше, реалізація СОМ для Windows вимагала, щоб в системному реєстрі зберігалася вся інформація про всі компоненти в системі. Користувачеві доводилося реєструвати компоненти при установці програм і стирати відповідну інформацію при видаленні програм. При спробі видалення програм виникала небезпека того, що зміни, внесені до реєстру, вплинуть на роботу інших програм. Варто було серйозно пошкодити реєстр, і система взагалі переставала працювати. Більш того, установка нової версії компоненту нерідко порушувала роботу програм, розрахованих на ранішу версію компоненту.

У Windows 98 була вперше представлена концепція паралельного виконання (side-by-side execution); це означало, що додаток міг використовувати локальний екземпляр компоненту СОМ, що знаходиться в каталозі додатку, замість екземпляра, зареєстрованого в системі. Справедливості ради слід сказати, що паралельне виконання так і не вирішило проблеми з «кошмаром DLL», додатково воно працює тільки в Windows 98, 2000 і ХР — і те якщо про це спеціально поклопочеться розробник програми.

Давайте подивимося, що відбувається на рівні реєстру при реєстрації компонентів СОМ.

1. Розробник створює для компоненту глобально-унікальний ідентифікатор (GUID).
   
2. Розробник створює для компоненту програмний ідентифікатор (PROGID).
   
3. Утиліта реєстрації пов'язує PROGID компоненту з GUID, створюючи відповідний запис в реєстрі.
   
4. Утиліта реєстрації заносить повний шлях до двійкового файлу компоненту в реєстр і пов'язує його з GUID компоненту.
   
5. Утиліта реєстрації також може зберегти в реєстрі додаткові відомості про компонент — наприклад, тип потокової моделі.
   

При спробі використання компоненту відбувається наступне:

1. Розробник додатку створює екземпляр компоненту, використовуючи PROGID.
   
2. СОМ шукає в реєстрі GUID компоненту.
   
3. СОМ знаходить двійковий файл компоненту.
   
4. СОМ створює екземпляр компоненту.
   

Не дивлячись на велику кількість виконуваних операцій, головні проблеми виникають при копіюванні в систему нового файлу з компонентом, оновленням реєстру, що не супроводиться, і при зміні GUID. Додаток, який раніше благополучно працювало, працювати перестає. Це пов'язано з тим, що в механізмі установки СОМ не передбачено нормальних засобів для контролю версії компонентів.

Складки.NET

Як було сказано на початку цього розділу, процес установки в .NET часто зводиться до простого копіювання файлів, після чого програма готова до негайного запуску. Якщо видалити скопійовані файли, то працювати перестає тільки ця конкретна програма. У цьому процесі не використовується реєстр і не враховуються залежності між компонентами. Щоб ця схема нормально працювала, в .NET використовується концепція збірки.

З технічної точки зору збірка (assembly) в .NET є мінімальною встановлюваною одиницею програмної коди. Збірка оформляється у вигляді автономного ЕХЕ-файла або у вигляді бібліотеки DLL, на яку можна посилатися з інших застосувань. Проте збірка містить щось більше, ніж звичайний IL-код, компільований і виконуваний виконавчим середовищем .NET. Як мінімум, збірка складається з одного або декількох модулів і класів, що відкомпілювалися в IL-код, і метаданих (даних, що описують дані [ Префікс «мета» для подібних абстракцій другого порядку позаїмствован з метаматематики — області математики, присвяченої опису самих математичних об'єктів. ]), які описують збірку і функціональність вхідних в неї класів. Метадані є частиною збірки, тому в документації збірки названі самодокументіруємимі. У багатьох ситуаціях збірка складається з одного файлу, але зустрічаються і багатофайлові складки. Наприклад, в збірку можуть входити ресурсні файли, графічні зображення і навіть додаткові Exe/dll-файли. У будь-якому випадку збірка є мінімальним об'єктом .NET, для якого проводиться контроль версії або задаються привілеї.

В більшості випадків створюються однофайлові складки, що складаються з одного Ехе-ілі DLL-файла.

Складки бувають закритими (private) і загальними (shared). Закриті складки завжди знаходяться в каталозі додатку або в одному з його підкаталогів. Загальні складки зберігаються в глобальному кеші складок (GAC, global assembly cache). Почнемо із закритих складок, оскільки саме вони використовуються за умовчанням для рішень, побудованих в VS .NET IDE. Із загальними складками справа йде складніше, і ми займемося ними пізніше.

Зазвичай у закритих складок не буває проблем з несумісністю версій, проте вони вимагають додаткових витрат дискового простору, якщо в системі доводиться зберігати декілька копій одного файлу в різних каталогах [ У наш час дисковий простір обходиться так дешево, що ці витрати з лишком компенсуються зручностями, зв'язаними з використанням закритих складок. ]. При створенні посилань на збірку командою Project > Add Reference за умовчанням в каталозі додатку створюється новий екземпляр закритої збірки. Ми рекомендуємо по можливості обмежуватися використанням закритих складок.

Для управління складками використовуються конфігураційні файли у форматі XML. Конфігураційний файл повинен знаходитися в одному каталозі з файлом, що містить точку входу в збірку. З його допомогою можна управляти привілеями, призначати каталоги для пошуку залежних DLL, а також указувати інші відомості, необхідні для завантаження збірки.