Посилання на збірки, ASP, Програмування, статті

Коли потрібно використовувати будь-який тип (клас або структуру),
міститься в іншій збірці, необхідно встановити посилання на цю
збірку. Таке посилання зберігається в маніфесті клієнтської збірки і
ідентифікує ім'я і версію збірки, на яку вона вказує. Visual
Studio. NET підтримує два типи посилань: на проекти і на файли.

Використання посилань на проекти

У діалоговому вікні Add Reference на вкладці Projects
перераховуються інші проекти поточного рішення. Тут можна створити
посилання з даного проекту на інший проект у тому ж рішенні.
Використання таких посилань є рекомендованим способом звернення до
іншим зборках і дає багато переваг.

ПриміткаПосилання на проекти – головна причина, по
якої слід по можливості завжди застосовувати модель на основі одного
рішення (single soluton model) або одного рішення, розбитого на частини
(partitioned single soluton model).

Переваги посилань на проекти

Посилання на проекти дають наступні переваги.

  • Працюють на всіх комп'ютерах, на які завантажені рішення і його
    проекти. Це пояснюється тим, що в файл проекту поміщається GUID
    (Globally Unique Identifier), унікально ідентифікує в контексті
    поточного рішення проект, на який є посилання.
  • Дозволяють Visual Studio. NET відстежувати залежності проекту і
    визначати правильний порядок його складання.
  • Не допускають відсутності на даному комп'ютері збірок, на які
    є посилання.

  • Забезпечують автоматичне відстежування змін в
    конфігурації проекту. Наприклад, якщо ви збираєте рішення в
    отладочной конфігурації, посилання вказують на налагодження складання
    (Assemblies), що генеруються для цих проектів, а якщо ви збираєте
    рішення у фінальній конфігурації – на кінцеві версії збірок. Те
    Тобто ви можете автоматично переключатися з отладочной конфігурації
    на фінальну, нічого не змінюючи в посиланнях.
  • Дозволяють Visual Studio. NET виявляти і запобігати кругові
    залежності (circular dependencies).

Використовуйте файлові посилання тільки при необхідності

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

  • Щоб послатися на складання. NET Framework, виберіть її зі списку
    на вкладці.NET діалогового вікна Add References.
  • Знайдіть потрібну збірку, натиснувши кнопку Browse в діалоговому
    вікні Add Reference.

Якщо ви створюєте файлову посилання, шлях до збірки запам'ятовується у файлі
проекту з контрольованим вихідним кодом (source controlled project
file). Для локальних збірок зберігається відносний шлях, а для збірок,
розміщуються на серверах, – повний мережевий шлях (див. фрагмент коду нижче).
Зверніть увагу на атрибути HintPath.

<References>

  <Reference

     Name = "System.XML"

     AssemblyName = "System.Xml"

HintPath = "........ WINDOWSMicrosoft.NETFrameworkv1.0.3423System.XML.dll "

  />

  <Reference

    Name = "Lib1"

    AssemblyName = "Lib1"

HintPath = BuildServerLatestReleaseSharedComponentSomeControl.dll

  />

</References>

ПриміткаКомпонування типу System.XML.dll розміщуються
в кеші глобальних збірок (Global Assembly Cache, GAC). Однак посилання
ніколи не вказують безпосередньо на складання в GAC. Коли ви обираєте
збірку на вкладці. NET діалогового вікна Add References, насправді
створюється посилання на копію збірки, що знаходиться в папці
%windir%Microsoft.NETFramework<version>.

Вказуйте для посилань на проекти та файли copy local = true

З кожною посиланням зв'язується атрибут copy local. При
додаванні посилання Visual Studio. NET автоматично визначає початкове
значення цього атрибута (true або false). Атрибут одержує
значення false, Якщо посилання вказує на складання, копія якого
повинна міститися в GAC, і true в іншому випадку.

Не змінюйте значення цього атрибуту за замовчуванням. Коли атрибут
copy local
дорівнює true, Visual Studio. NET копіює збірку,
задається посиланням (і будь-які інші, від яких залежить ця збірка), в
вихідну папку клієнтського проекту.

Наприклад, якщо клієнтський проект посилається на складання Lib1, а Lib1
залежить від Lib2 і Lib3, Visual Studio. NET при складанні проекту
автоматично копіює Lib1, Lib2 і Lib3 в локальну вихідну папку
цього проекту.

Автоматичне відстеження залежностей

Кожен раз, коли ви збираєте локальний проект, складальна підсистема
порівнює дату і час складання, на яку вказує посилання, з датою і
Згодом її робочої копії на вашому комп'ютері. Якщо у збірки, що задається
посиланням, дата і час більш пізні, ця нова версія копіюється в
локальну папку. Одна з переваг такого підходу – посилання,
встановлена ​​розробником, не блокує DLL збірку на сервері і не
створює перешкод складного процесу.

Посилання на проекти в системах на основі одного рішення або одного
рішення, розбитого на частини

По можливості намагайтеся використовувати посилання на проекти, а не
файлові посилання.

Якщо ви прийняли модель на основі одного рішення або модель на основі
одного рішення, розбитого на частини, то використовуйте файлові посилання,
тільки коли вам потрібно звертатися до зовнішніх збірок (тобто до тих,
які не створюються в складальному процесі на вашій системі). До таких
зборках відносяться:

  1. Збірки. NET Framework, посилання на які задаються на вкладці.NET
    діалогового вікна Add References. У середовищі груповий
    розробки такі збірки не створюють проблем, так як на всіх
    комп'ютерах вони знаходяться в загальному для всіх проектів місці.
  2. Складання зовнішніх систем (outer system assemblies), що підключаються в
    діалоговому вікні Add References за допомогою кнопки
    Browse
    . До них відносяться компоненти сторонніх постачальників і
    збірки, створені у вашій компанії, але не входять до складу поточної
    системи. Про те, як керувати цим типом збірок, див

    Використовуйте віртуальний диск для більшої гнучкості
    .
  3. Переваги створення посилань на збірки, що зберігаються на сервері збірок

    Такий підхід дає наступні переваги.

    • Посилання гарантовано вказує на останню версію збірок, так
      як ці збірки регулярно (наприклад, щодня) оновлюються в
      складальному процесі.
    • Шляхи в посиланнях, що містять букви віртуальних дисків або
      UNC-пути, можна використовувати на всіх комп'ютерах розробників і на
      сервері збірок.

    Недоліки створення посилань на збірки, що зберігаються на сервері збірок

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

    • У вас немає прямого контролю над тим, в який саме момент
      оновлюються збірки, на які ви посилаєтесь. В результаті можлива
      ситуація, при якій нова версія збірки створюється на сервері в
      самий невідповідний момент, наприклад у той час, коли ви займаєтеся
      розробкою і налагодженням іншого модуля системи. Хоча централізований
      складальний процес зазвичай запускається ночами, проміжні версії
      збірок іноді створюються і в робочий час. Генерація проміжних
      версій може викликати проблеми.
    • Не підтримується розробка в автономному (ізольованому)
      режимі. Вам необхідно пряме з'єднання з сервером збірок всякий
      раз, коли ви збираєте локальний проект, який посилається на складання на
      сервері.

    Ізольована розробка

    Якщо при розробці потрібен високий рівень ізоляції, ведіть
    ізольовану розробку програми. Для реалізації такого підходу
    потрібні такі дії.

    1. Скопіюйте вихідні збірки з сервера зборок в якій-небудь
      стандартний каталог на своєму комп'ютері. Це можна робити вручну
      або за допомогою сценарію (script).
    2. Створіть загальнодоступний віртуальний диск (наприклад диск R), щоб
      всі розробники могли посилатися на збірки, вказуючи один і той же
      шлях.
    3. Встановіть посилання на локальні збірки, вказавши в шляхах до них
      букву цього віртуального диска (диска R).
    4. Періодично перевіряйте, чи не з'явилися на сервері нові версії
      збірок, і вручну копіюйте їх на локальний комп'ютер.

    Використовуйте віртуальний диск для більшої гнучкості

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

    УвагаВсі розробники групи повинні використовувати
    одну і ту ж літеру диска, так як вона зберігається у файлі проекту з
    контрольованим вихідним кодом (source controlled project file), як
    показано в наступному фрагменті коду.

    <References>
    
      <Reference
    
        Name = "Lib1"
    
        AssemblyName = "Lib1"
    
    HintPath = "R: LatestReleaseSharedComponentSomeControl.dll"
    
      />
    
    </References>
    

    Ще одна перевага використання літери віртуального диска –
    можливість легко зіставити її з іншим шляхом. Наприклад, велику частину
    часу буква віртуального диска може бути зіставлена ​​з шляхом до
    серверу збірок, а на якийсь час, коли потрібно попрацювати
    ізольовано, – з локальним шляхом.

    Створюючи файлові посилання, завжди вказуйте фінальні версії збірок

    Сценарій збірки регулярно (зазвичай щодня) оновлює збірки,
    зберігаються на сервері, до поточних версій. Як правило, сценарій збірки
    генерує налагодження та фінальні версії збірок. Розробники використовують
    налагодження DLL, а тестувальники – фінальні. При цьому застосовується
    наступна схема.

Посилання на Web-сервіси

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

Якщо ж Web-сервіси входять до складу системи на основі декількох
рішень, то не всім розробникам потрібно встановлювати Web-сервіс
локально.

У системах на основі кількох рішень розробник Web-сервісу
повинен опублікувати його на центральному Web-сервері, щоб інші
могли звертатися до сервісу зі своїх проектів.

Контроль версій Web-сервісів при розробці

Web-сервіси, які використовуються в процесі розробки, з часом
модифікуються. Тому потрібно слідкувати за тим, щоб на Web-сервері
зберігалися останні версії цих сервісів.

У багатьох відносинах проблеми контролю версій при роботі з
Web-сервісами аналогічні проблемам контролю версій при роботі з базами
даних. Коли схема бази даних оновлюється, слід планувати і
координувати зміни так, щоб залежні клієнтські програми
можна було оновлювати синхронно зі змінами схеми.

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

ПриміткаПри зміні реалізації сервісу на
координацію витрачається менше зусиль, ніж при модифікації інтерфейсу.
Однак і в тому і в іншому випадку група, що розробляє Web-сервіс,
повинна повідомити про зміни іншим розробникам і групам
розробників.

Завжди використовуйте динамічні URL

Якщо ви збираєтеся звертатися до Web-сервісу, то перш за все повинні
додати у свій проект Web-сервері. При цьому генерується проксі-клас,
через який ваш додаток буде взаємодіяти з Web-сервісом.
Спочатку в код проксі-класу поміщається статичний URL (Uniform Resource
Locator) Web-сервісу, наприклад http://localhost або
http://SomeWebServer.

УвагаДля Web-сервісів в поточному рішенні,
виконуваних на вашому комп'ютері, завжди використовуйте URL
http://localhost, який буде працювати на всіх комп'ютерах, а не
http://MyComputerName.

Статичний URL, що вбудовується в проксі, – звичайно не той URL, який
потрібний при тестуванні або використанні програми у виробничій
середовищі. Зазвичай потрібний URL змінюється при переході програми з етапу
розробки на етап тестування, а потім при його розгортанні в
виробничому середовищі. Вирішити проблему налаштування URL можна двома
способами.

  • Програмно вказувати URL Web-сервісу при створенні екземпляра
    проксі-класу.
  • Застосувати більш гнучкий підхід, при якому URL НЕ
    "Зашивається" у проксі: вказати для властивості URL Behavior
    посилання на Web-сервіс значення dynamic. Рекомендується
    використовувати саме такий підхід. Коли властивості присвоюється
    значення dynamic, В проксі-клас додається код, що зчитує
    URL Web-сервісу з розділу <appSettings> файлу конфігурації
    додатки – Web.config для Web-додатки або SomeApp.exe.config
    для Windows-програми.

Крім того, при динамічному завданні URL можна вказати
користувальницький файл конфігурації, який перевизначає параметри,
визначені в головному файлі конфігурації програми. Завдяки цьому
окремі розробники (і члени групи тестування) можуть тимчасово
перевизначати посилання на Web-сервіс, вказуючи який-небудь інший URL.

Як застосовувати динамічний URL і користувальницький файл конфігурації

Щоб домогтися максимальної гнучкості у розробці та виробничому
використанні програми, в посиланнях на Web-сервіси вказуйте для
властивості URL Behavior значення dynamic. URL для
застосування Web-сервісів у виробничому середовищі задавайте у файлі
конфігурації програми, а для розробки та тестування – у
користувальницькому файлі конфігурації. Якщо такий файл відсутній,
використовуються параметри з файлу конфігурації програми.

Щоб вказати URL Web-сервісу в користувальницькому файлі конфігурації

  1. Додайте атрибут file="user.config" в елемент
    appSettings
    головного файлу конфігурації програми. Після цього
    виконуюча середовище при зверненні до інформації з розділу
    appSettings
    буде автоматично зчитувати параметри з
    користувальницького файлу конфігурації. Якщо такого файлу немає, беруться
    параметри з головного файлу конфігурації програми – помилка періоду
    виконання не генерується.

    <configuration>
     <appSettings file="user.config">
    <Add key = "ClientApplication.SomeServer.SomeService"
    value = "http://ProdWeb/myXmlWebService/Service1.asmx" />
     </appSettings>
    </configuration>
    

    У попередньому прикладі ClientApplication.SomeServer.SomeService
    – Повністю певне ім'я проксі-класу Web-сервісу.
    ClientApplication.SomeServer
    – Це простір імен, а
    SomeService
    – Ім'я проксі-класу.

  2. Створіть файл User.config (у папці, де знаходиться файл
    конфігурації програми) і додайте в нього запис appSettings,
    містить пару "ключ-значення", яка ідентифікує URL
    Web-сервісу, як показано в наступному фрагменті коду. Зверніть
    увагу, що в цьому прикладі URL вказує на локальний Web-сервер,
    і, крім того, у файлі User.config немає елементу <configuration>.

    <appSettings>
    <Add key = "ClientApplication.SomeServer.SomeService"
    value = "http://localhost/myXmlWebService/Service1.asmx" />
    </appSettings>
    
  3. Не ставте файл User.config на контроль в VSS. Тоді кожен
    розробник (або група тестування) зможе явно вказувати
    використовуваний ним URL в своєму файлі User.config. У головному файлі
    конфігурації програми слід задати адресу виробничої версії
    Web-сервісу. Ця адреса використовується, коли файл User.config
    відсутня.
    РадаЗа замовчуванням користувальницький? файл конфігурації
    автоматично додається до VSS. Щоб цього уникнути, в Solution
    Explorer клацніть файл правою кнопкою миші і виберіть Exclude
    From Project
    . Щоб потім побачити файл в Solution Explorer,
    клацніть значок Show All Files вгорі вікна Solution Explorer.

    УвагаWeb-додатки, які звертаються до
    користувальницькому файлу конфігурації, не враховують автоматично
    зміни в цьому файлі. Це відбувається тільки при оновленні файлу
    Web.config. Таким чином, зміни в призначеному для користувача файлі
    конфігурації не проявляються в додатку відразу ж. Потрібно вручну
    зупинити і перезапустити Web-додаток. Це ще одна причина, по
    якої слід використовувати файл Web.config для завдання параметрів,
    застосовуваних у виробничому середовищі, а файл User.config – тільки
    для параметрів, що застосовуються при розробці та тестуванні.

Оновлення посилань на Web-сервіси

Щоб оновити існуюче посилання на Web-сервіс, в Visual Studio
. NET у вікні Solution Explorer клацніть файл правою кнопкою миші і
виберіть Update. При такій збірці проекту буде завантажений
WSDL-документ з новою інформацією про сервіс і згенерований новий
проксі-клас Web-сервісу.

Посилання на бази даних

За допомогою файлу User.config можна управляти і посиланнями на бази
даних, що мають вид рядків підключення. Перевага цього підходу в
тому, що кожен розробник може легко поставити власну рядок
підключення в особистому файлі User.config. Будь-які зміни, внесені одним
розробником, наприклад, коли він задає з'єднання з локальною базою
даних, щоб протестувати свій модуль, не впливають на діяльність
інших розробників.

Крім того, призначені для користувача файли конфігурації можна застосовувати для
управління параметрами, специфічними для середовища, наприклад для тестової. В
тестової середовищі також можна застосовувати файл User.config, який посилається на
тестову базу даних.

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

Завдання рядків підключення до бази даних через користувальницькі файли
конфігурації

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

Щоб зберегти рядка підключення до бази даних в користувальницькому
файлі конфігурації

  1. Додайте атрибут file="user.config" в елемент
    appSettings
    головного файлу конфігурації вашої програми і
    вкажіть рядок підключення за умовчанням в головному файлі
    конфігурації. Вона застосовується, якщо користувач не перевизначає
    її у своєму файлі конфігурації.

    <configuration>
     <appSettings file="user.config">
      <add key="DBConnStr"
    value = "server = PRODDB; Integrated Security = SSPI; database = Accounts" />
     </appSettings>
    </configuration>
    
  2. Щоб перевизначити параметри, що містяться в головному файлі
    конфігурації програми, створіть файл User.config (в тій папці, де
    зберігається файл конфігурації програми) і додайте в нього аналогічну
    запис appSettings. Зауважте, що наступна рядок
    підключення змушує посилатися на локальну базу даних.

    <appSettings>
      <add key="DBConnStr"
    value = "server = (local); Integrated Security = SSPI; database = Accounts" />
     </appSettings>
    
  3. У своєму проекті, щоб отримати рядок підключення з
    користувальницького файлу конфігурації (якщо такий файл є) або з
    файлу конфігурації програми (якщо користувацького файлу немає),
    напишіть код наступного вигляду. Він звертається до статичного властивості
    AppSettings класу
    System.Configuration.ConfigurationSetting
    .

    using System.Configuration;
    private string GetDBaseConnectionString()
    {
    return ConfigurationSettings.AppSettings ["DBConnStr"];
    }
    

Розробка баз даних

Існує два основних підходи до розробки у груповий середовищі баз
даних:

  • з використанням централізованого сервера (або серверів) бази
    даних;
  • із застосуванням централізованого сервера (або серверів) бази
    даних і локальних баз даних на комп'ютерах розробників.

Централізовані сервери баз даних

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

  • Не надавайте розробникам адміністративні права доступу до
    серверу бази даних і не дозволяйте окремим розробникам змінювати
    схему. Ретельно стежите за середовищем, в якому працює група, так
    як зміни, що вносяться одним розробником, можуть вплинути на
    роботу інших.
  • Видайте розробникам специфічні дозволу; наприклад,
    дозвольте їм записувати в базу даних збережені процедури, функції і,
    можливо, уявлення (views).
  • Управляйте змінами в схемі і інших об'єктах, наприклад в
    збережених процедурах, за допомогою сценаріїв з контрольованими вихідними
    текстами.
  • Використовуйте сценарії, щоб спростити створення баз даних.
  • Створіть окремі екземпляри бази даних для різних напрямків
    розробки, оскільки параметри конфігурації можуть бути різними для
    кожного з проектів, що розробляються.

Локальні бази даних

Основна проблема у використанні усіма розробниками однієї або
декількох централізованих баз даних – складність підтримки
цілісного набору тестових даних. Досить імовірно, що тестування
модуля одним розробником вплине на діяльність інших, так як
тестові дані можуть мінятися досить часто.

Тому в багатьох випадках на кожен комп'ютер розробника
встановлюється Microsoft SQL Server Developer Edition, що
дозволяє кожному розробнику створити на своєму комп'ютері ізольовану
середу тестування.

Для внесення змін використовуйте сценарії бази даних

Для внесення будь-яких змін в базу даних, що зберігається на локальному
або централізованому сервері, застосовуйте сценарії з контрольованими
вихідними текстами. Пишіть сценарії для будь-яких змін, навіть якщо їх
можна було б виконати вручну в Enterprise Manager. Використовуйте
сценарії бази даних (по можливості з веденням аудиту та журналу
помилок), щоб:

  • забезпечити можливість створення бази даних з "нуля" (разом з
    збереженими процедурами і т. д.);
  • забезпечити завантаження "свіжого" набору тестових даних;
  • зберегти зміни у схемі бази даних та її об'єктах.

Проекти баз даних в Visual Studio. NET

Сценарії баз даних повинні зберігатися у вигляді вихідних текстів і
контролюватися VSS. Існує два способи керування сценаріями.

  • Розробляти сценарії поза IDE (Integrated Development
    Environment) Visual Studio. NET і вручну створювати структуру папок,
    яка може використовуватися VSS. Так, можна створити в
    $/Projects/SystemName
    підпапку Database Objects
    папку підпроекту, де зберігаються пов'язані з базі даних код і
    об'єкти, а в неї в свою чергу створити підпапки, які служать
    контейнерами для об'єктів різних видів, наприклад: Tables and
    Views
    , Diagrams and Documentation і
    Stored Procedures and Functions
    .
  • Використовувати проекти баз даних Visual Studio. NET. Це просто
    проекти, які складаються з файлів і дозволяють зберігати і виконувати
    сценарії бази даних, а також зберігати іншу інформацію про базу
    даних, наприклад документацію або складальні файли. У Visual Studio
    . NET інтегрований редактор коду Transact-SQL, візуальний інструмент
    Query Builder та підтримується налагодження сценаріїв T-SQL. Перевага
    такого підходу – у тісній автоматичної інтеграції з VSS, а також у
    інтеграції з іншими типами проектів.

Додаткову інформацію про проекти баз даних у розділі «Managing
Data with Database Projects within the Developing with Visual Studio
.NET" Microsoft MSDN® Library. Крім того, проведіть пошук в
MSDN за ключовими словами "Large Database Projects".

Посилання на COM-об'єкти

Коли ваш код звертається до COM-об'єкту, для перетворення. NET-типів
в COM-типи (і назад) використовується Interop-складання. Якщо COM-об'єкт
викликається з керованого коду, то насправді відбувається звернення до
проксі-об'єкту в Interop-складання. Проксі спочатку виконує необхідні
перетворення типів, а потім викликає COM-об'єкт, який робить те, що від
нього вимагається.

Завжди створюйте сумісні Interop-збірки

При груповій розробці, якщо ви й інший програміст звертаєтеся до
однієї і тієї ж DLL COM-об'єкта з двох різних проектів, створюються дві
Interop-збірки – по одній для кожного проекту.

У більшості випадків у цих двох збірках містяться одні і ті ж
типи, і ви можете безпечно передавати посилання на COM-об'єкт з одного
проекту в інший (через Interop-складання).

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

  1. Всі Interop-збірки слід генерувати по одній і тій же версії
    бібліотеки COM-типів.
  2. Ідентифікація всіх Interop-збірок повинна бути однаковою. Така
    ідентифікація включає:

    1. назва файлу без розширення;
    2. відкритий ключ (може бути порожнім);
    3. версію;
    4. культуру (для коду – зазвичай нейтральна культура).

Перераховані вище умови зазвичай виконуються, коли ви генеруєте
Interop-складання в середовищі Visual Studio. NET, вибираючи бібліотеку COM-типів
в діалоговому вікні Add References. Єдиний виняток
пов'язано з тим, що в Visual Studio. NET (в C #-проектах) можна
привласнювати Interop-зборках суворі імена (використовуючи властивість Wrapper
Assembly Key File, доступне у вікні властивостей проекту). У цьому випадку
може виявитися, що два розробники створять дві різні
Interop-збірки, несумісні один з одним.

Щоб гарантувати в середовищі групової розробки, що для будь
версії бібліотеки COM-типів існує тільки одна Interop-збірка,
використовуйте один з двох підходів.

  1. Завжди застосовуйте первинні Interop-збірки (Primary Interop
    Assemblies, PIA).
  2. Якщо PIA недоступна, створіть Interop-складання вручну (за допомогою
    tlbimp.exe), а потім:

    1. при необхідності надайте збірці суворе ім'я;
    2. безпосередньо дозволите збірку в проекти, які повинні на неї
      посилатися.

Обидва ці підходи описуються в наступному розділі.

По можливості використовуйте PIA

PIA (Primary Interop Assembly) – це Interop-збірка, офіційно
підписана розробником COM-об'єкта і призначена для
використання у всіх випадках. Якщо у вас немає PIA, запитайте її у
розробника COM-об'єкта.

Розглядайте PIA як збірку зовнішньої системи і розміщуйте її прямо в
проект, який на неї посилається. В результаті вона копіюється в папку
проекту. Встановіть файлову посилання на збірку, що міститься в папці
проекту. Це робиться точно так само, як вже описувалося в розділі

Управління версіями збірок
глави 5 "Процес складання".

Для контролю CLSID обслуговується компонента, що зберігається в каталозі
COM +, і щоб уникнути появи нових версій всякий раз, коли
розробник повторно збирає обслуговується компонент, використовуйте один
з двох способів.

  1. Явно задавайте CLSID через атрибут Guid:
    [Guid("2136360E-FEBC-475a-95B4-3DDDD586E52A")]
    public interface IFoo
    {
    }
     
    [TransactionAttribute(TransactionOption.Required),
    Guid("57F01F20-9C0C-4e63-9588-720D5D537E66")]
    public class Foo: ServicedComponent, IFoo
    {
    }
    
  2. Для збірок обслуговуваних компонентів задавайте статичні
    номери версій і не застосовуйте схему нумерації версій "1.0 .*",
    діючу в Visual Studio. NET за замовчуванням. Докладніше про
    управлінні версіями збірок див

    Процес складання
    .

    Схожі статті:


    Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

    Коментарів поки що немає.

    Ваш отзыв

    Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *

    *