Посилання на складання

Коли потрібно використовувати будь-який тип (клас чи структуру),
міститься в іншій збірці, необхідно встановити посилання на цю
збірку. Таке посилання зберігається в маніфесті клієнтської збірки і
ідентифікує ім'я і версію збірки, на яку вона вказує. 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
    . До них відносяться компоненти сторонніх постачальників і
    збірки, створені у вашій компанії, але не входять до складу поточної
    системи. Про те, як керувати цим типом збірок, див

    Включення збірок зовнішніх систем в проекти.

Файлові посилання в системах на основі кількох рішень

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

Вибір місцезнаходження зборок, на які є посилання

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

  • Створити посилання на складання, яка знаходиться на сервері збірок,
    вказавши або букву віртуального диска, або UNC-шлях (Universal
    Naming Convention).
  • Скопіювати групу зборок, що генеруються складальним процесом, з
    сервера збірок на локальний комп'ютер і створити локальну посилання,
    вказавши букву віртуального диска. Про застосування віртуальних дисків читайте
    у розділі

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

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

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

  • Посилання гарантовано вказує на останню версію збірок, так
    як ці збірки регулярно (наприклад, щодня) оновлюється в
    складальному процесі.
  • Шляхи в посиланнях, що містять букви віртуальних дисків або
    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, а тестувальники – фінальні. При цьому застосовується
наступна схема.

  • Як розробник, ви встановлюєте собі налагодження варіанти DLL,
    щоб використовувати їх при розробці та тестуванні модулів.
  • Члени групи тестування встановлюють фінальну версію системи
    і завжди тестують фінальні версії DLL. Не затягуйте з генерацією
    фінальної версії до настання дати випуску розроблюваної вами
    системи, так як у фінальній версії можуть виникнути проблеми,
    яких не було в перевіреній.
    Для підтримки та налагоджувальних, і фінальних версій складальний процес
    копіює збірки в розміщуються на сервері збірок папки Release і
    Debug. Докладну інформацію про це див в розділі 5 "Складальний
    процес ".
    Як розробник, ви повинні при створенні посилань завжди вказувати
    збірки з папки Release. Це пояснюється наступними причинами.
  • Саме ці версії збірок, від яких залежить ваше застосування, в
    кінцевому підсумку будуть використовуватися на практиці.
  • Вам ніколи не знадобиться переадресовувати файлові вказує
    папки Debug на папку Release, щоб згенерувати фінальну версію.
    Файлові посилання на відміну від посилань на проекти не оновлюються
    динамічно при зміні конфігурації.

При ізольованій розроблення та налагодження задавайте шляху до посилань

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

  1. Скопіюйте рішення на свій комп'ютер.
  2. Зберіть налагоджувальну версію збірки.
  3. Задайте в клієнтському проекті шлях до посилань, що вказує на
    налагоджувальну вихідну папку збірки, на яку посилається ваш проект.
  4. Заново зберіть клієнтський проект і запустіть його. У результаті
    у вихідний папці клієнтського проекту перебуватиме локальна
    налагоджувальна версія збірки, на яку посилається ваш проект. Тепер
    можна приступити до налагодження цієї збірки в покроковому режимі.
  5. Коли ви завершите налагодження і захочете повернутися до складання,
    яку зазвичай використовуєте, видаліть запис шляху до посилань.

Що таке шлях до посилань?

Шлях до посилань (reference path) – це параметр, яким задавалося
індивідуально для кожного комп'ютера і кожного розробника і який
зберігається у вигляді XML-елемента у файлі для користувача параметрів проекту
(*. Csproj.user або *. vbproj.user). Шлях до посилань допомагає Visual Studio
. NET знаходити збірки, на які посилається проект.

УвагаЯкщо ви будете дотримуватися наведених вище
рекомендаціями і використовувати для звернення до зборках або посилання на
проекти, або файлові посилання (з віртуальними дисками), то Visual Studio
. NET на будь-якому комп'ютері зможе безпосередньо вирішувати всі посилання, і вам
швидше за все не потрібно задавати шляхи до посилань. Однак шлях до
посиланнях іноді може виявитися корисним, оскільки дозволяє
перевизначити шлях, заданий елементом <HintPath> у файлі
проекту з контрольованим вихідним кодом.

Дозвіл посилань на збірки при складанні проекту

Під час складання Visual Studio. NET дозволяє посилання на складання,
виконуючи пошук в наступних місцях у зазначеному порядку.

  1. В одній з папок проекту. Збірка буде там, якщо ви додали її
    до проекту командою меню Add Existing Item. Папки проектів –
    будь-які папки, які відображаються в Solution Explorer (якщо не встановлено
    режим Show All Files).
  2. У папках, заданих атрибутом ReferencePath елемента <Settings>
    у файлі для користувача параметрів проекту. У цьому атрибуті може
    міститися список папок, розділених комами.
  3. За посиланнями з атрибуту <HintPath> у файлі проекту.
    У папках, заданих параметрами реєстру. У цих папках зберігаються
    збірки, які відображаються на вкладці.NET діалогового вікна Add
    references
    . Докладніше про це див в розділі

    Використання вкладки. NET діалогового вікна Add Reference.

  4. У папці obj теки проекту (пошук збірок COM Interop).
    Докладніше про це див в розділі

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

Зауважте, що при використанні файлових посилань шлях до посилань,
зазначений у файлі для користувача параметрів проекту, має пріоритет
перед посиланнями в <HintPath>.

Ізольована розробка і тестування модулів

Шлях до посилань зручний і в тому випадку, коли ви ведете ізольовану
розробку та тестуєте модулі систем, що складаються з декількох рішень.
Наприклад, розглянемо два рішення – SA і SB; допустимо, у вирішенні SA є
проект PA, залежний від бібліотечного проекту PB, що входить до складу
рішення SB. Якщо вам потрібно вести ізольовану розробку і
протестувати модулі цих двох рішень перед складанням наступної версії
системи, ви можете змінити шлях до посилань в проекті PA на вихідну папку
проекту PB. Тоді можна внести зміни в проект PB, заново зібрати його
на локальному комп'ютері і тестувати PB, звертаючись до нього з рішення
SA.

При цьому не потрібно знову ставити рішення SB на контроль і чекати,
коли складальний процес в черговий раз перекомпілюються його складання.

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

Як задати шлях до посилань для певного проекту

Для встановлення в певному проекті шляху до посилань виконайте
наступні дії.

Щоб змінити шлях до посилань в даному проекті

  1. У Solution Explorer клацніть проект правою кнопкою миші, а потім
    виберіть Properties.
  2. Розкрийте папку Common Properties і клацніть
    Reference
    Path.
  3. Для проектів на C #: клацніть значок New Line і
    введіть новий шлях до посилань.
    – Або –
    Для проектів на Visual Basic. NET: введіть шлях до посилань у полі
    Folder
    і клацніть Add Folder.
  4. Клацніть OK, Щоб закрити діалогове вікно Properties.

Включення збірок зовнішніх систем в проекти

Кращий спосіб роботи з такими збірками (наприклад, з Web-елементами
сторонніх постачальників або з компонентами, не перекомпіліруемимі вашим
складальним процесом) – безпосередньо включати їх у проекти, які на них
посилаються. У принципі зі зборки зовнішніх систем треба працювати так само,
як з файлами. bmp або. gif.

Як включити збірку зовнішньої системи в проект і послатися на неї

  1. У Solution Explorer клацніть правою кнопкою миші проект, в
    який ви хочете додати посилання на складання, і виберіть Add
    Existing Item
    .
  2. Виберіть потрібну збірку і клацніть OK. Тоді збірка буде
    скопійована в папку проекту і автоматично додана в VSS
    (Передбачається, що даний проект вже контролюється VSS).
  3. Клацніть кнопку Browse в діалоговому вікні Add
    Reference
    і встановите посилання на файл зборки в папці проекту.

Переваги

Такий підхід дає дві переваги.

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

Спільне використання збірок зовнішніх систем у VSS

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

Цю проблему можна вирішити, налаштувавши VSS на спільне використання
складання проектами, які з нею працюють. Тоді досить оновити файл
складання в одному з проектів. Щоб актуалізувати копії, використовувані
іншими проектами, в Solution Explorer клацніть проект правою кнопкою
миші і виберіть Get Latest Version (Recursive).

Використання вкладки. NET діалогового вікна Add Reference

На вкладці .NET діалогового вікна Add Reference
показуються системні збірки і PIA-збірки (Primary Interop Assembly),
що входять до складу. NET Framework, і, можливо, інші збірки. На цій
вкладці зазвичай (але не обов'язково) перераховуються збірки, встановлені в
GAC.

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

Наприклад, можна змінити реєстр так, щоб його записи вказували імена
папок зі збірками, які генеруються вашим сценарієм збірки (локально
або на сервері збірок). Тоді розробники зможуть посилатися на ці
складання через вкладку.NET, Не використовуючи кнопку Browse.

Додавання на вкладку. NET власних збірок

  1. Створіть підрозділ (наприклад InnerSystemAssemblies) У
    одному з наступних розділів реєстру:

    HKEY_LOCAL_MACHINESoftwareMicrosoft.NETFrameworkAssemblyFolders
    HKEY_CURRENT_USERSoftwareMicrosoft.NETFrameworkAssemblyFolders
    
  2. Задайте в цьому розділі параметр за умовчанням з ім'ям папки,
    містить ваші збірки.
  3. Якщо ви відкрили Visual Studio. NET, то, щоб внесені
    зміни вступили в силу, закрийте цю середу і перезапустіть.

Посилання на 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 як збірку зовнішньої системи і розміщуйте її прямо в
проект, який на неї посилається. У результаті вона копіюється до папки
проекту. Встановіть файлову посилання на складання, що міститься в папці
проекту. Це робиться точно так само, як вже описувалося в розділі

Включення збірок зовнішніх систем в проекти.

ПриміткаPIA, що поставляються з. NET Framework,
знаходяться в папці Program FilesMicrosoft.NETPrimary Interop
Assemblies. Коли ви отримуєте нові PIA, не пишіть в цю папку;
якщо ви так зробите, доведеться оновлювати такі папки на всіх
комп'ютерах розробників і на сервері збірок. Копіюйте PIA прямо в
папки проектів, які повинні на них посилатися.

Якщо у вас немає Primary Interop Assembly, використовуєте TLBIMP

Якщо у вас немає PIA, створіть єдину Interop-збірку з допомогою
утиліти Tlbimp.exe і при необхідності надайте їй суворе ім'я. Як і в
випадку PIA (і інших збірок зовнішніх систем), дозволите згенерувала
вручну Interop-складання в проекти, які повинні на неї посилатися. У
результаті збірка копіюється в локальну теку проекту, який буде
посилатися на неї як на файл.

Реєструйте COM-класи на локальному комп'ютері

Додавання Interop-збірки в проект не означає автоматичного
копіювання на локальний комп'ютер (і реєстрації) пов'язаної з нею COM
DLL. Тому ви повинні вручну реєструвати COM DLL на кожній робочій
станції. Це розплата за взаємодію з некерованим світом COM.

Виклик обслуговуються компонентів

Обслуговуваний компонент – керований. NET-клас, похідний від
класу ServicedComponent в просторі імен
System.EnterpriseServices
. Такі класи можуть розміщуватися в
COM +-додатках як у контейнерах і використовувати COM +-сервіси.

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

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

У обслуговуються компонентів повинні бути строгі імена (strong names).
Щоб привласнити суворе ім'я, вам знадобиться пара з відкритого та
закритого ключа, яку можна згенерувати утилітою Sn.exe. У багатьох
компаніях закритий ключ – ретельно оберігається секретна інформація, до
якій розробники не мають повсякденного доступу. Тому доводиться
використовувати відкладене (або часткове) підписання (delayed signing),
для якого достатньо лише відкритого ключа.

Часткове підписання призводить до того, що у PE-файлі (portable
executable) зборки створюється поле підстановки для сигнатури суворого
імені. Ця підписання відкладається на пізніший термін і
виконується в період між тестуванням системи та її випуском. Зазвичай
остаточне підписання збірок покладається на координатора збірки.

Використовуйте динамічну реєстрацію

Для підтримки динамічної реєстрації додайте в збірку
відповідні атрибути (наприклад ApplicationName,
ApplicationID
і ApplicationActivation). Тоді COM-типи,
пов'язані з вашими обслуговуваними компонентами, будуть автоматично
встановлені в каталог COM + на всіх комп'ютерах відразу після створення
обслуговується компонента.

Контролюйте CLSID, що зберігаються в каталозі COM +

Коли ви повторно генеруєте збірку, за замовчуванням їй присвоюється
новий номер версії, так як при створенні проекту Visual Studio. NET
присвоює атрибуту AssemblyVersion значення "1.0 .*". У результаті кожен
раз, коли збірка збирається заново, для обслуговуваних компонентів
генеруються нові CLSID (Class Identifiers).

Примітка
У проектах на C # і Visual Basic. NET це робиться трохи по-різному. У
проектах на C # версія збірки збільшується щоразу, коли ви
збираєте її заново, а в проектах на Visual Basic. NET – тільки коли ви
в перший раз заново збираєте проект після завантаження в Visual Studio
. NET. При наступних повторних збірках, які виконуються в тому ж примірнику
Visual Studio. NET, версія збірки не збільшується.

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

Управління версіями збірок глави 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 за замовчуванням. Докладніше про
    управлінні версіями збірок див

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

Це глава 4 керівництва з групової розробки в середовищі Visual Studio®
. NET і Visual SourceSafe. Главу 5 читайте за посиланням

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

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


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

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

Ваш отзыв

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

*

*