Управління залежностями системи контролю версій в Visual Studio Team System, Різне, Програмування, статті

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

Як використовувати дану статтю


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



Сценарії і рішення


Зазвичай реалізуються такі сценарії управління залежностями:


1. Використовується збірка, сформована іншим проектом у тому ж рішенні.


2. Використовується збірка, сформована іншим проектом в іншому рішенні.


3. Використовується збірка з іншого групового проекту.


4. Використовується збірка стороннього виробника.


Використання збірок, сформованих іншим проектом у тому ж рішенні


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


Використання збірок, сформованих проектами інших рішень


Існує два варіанти використання складання, сформованої проектом в іншому рішенні Visual Studio:



Посилання на файли більш уразливі, ніж посилання на проекти, так як вони не синхронізуються з конфігурацією збірки і не відслідковуються Visual Studio. Тому при зміні використовуваних збірок Visual Studio НЕ знає про те, що необхідно виконати збірку повторно.


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


Використання збірки з іншого групового проекту


При спільному використанні вихідного коду або двійкових файлів в групових проектах можливі два варіанти:



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


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


Використання складання стороннього виробника


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


Використання проектів


Наприклад, є груповий проект Visual Studio, Що містить спільно використовуваний декількома груповими проектами код бібліотеки. Можна зберігати проект в рамках вихідного групового проекту або створити окремий груповий проект спеціально для спільно використовуваного проекту. Для другого варіанту, коли створюється загальний спільний проект, структура каталогів системи контролю версій Microsoft Visual Studio Team Foundation Server (TFS) наступна (Рис. 6.1).

Управління залежностями системи контролю версій в Visual Studio Team System - Розробка і тестування - Програмування - Програмування, исходники, операційні системи

Рис. 6.1 Структура каталогів при загальному спільно використовуваному проекті


Існує два варіанти спільного використання проекту з власного групового проекту



Галуження


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


Зміни спільно використовуваного вихідного коду поширюються в ході процесу злиття гілок. При цьому рішення про поширення змін до спільно використовуваному вихідному коді стає більш явним, його простіше тестувати, але також виникають деякі додаткові витрати. Крім того, в цьому випадку істотно спрощується використання Team Build, оскільки відображення виконується на стороні сервера; немає відображення на стороні клієнта, яке повинно дублюватися на сервері збірки.


Наприклад, є два групових проекту, $ TeamProject1 і $ Common, і Common містить спільно використовуваний вихідний код. Тоді в проекті, що використовує
Common, створюється відгалуження спільно використовуваного каталогу. Отримуємо наступну структуру каталогів TFS (рис. 6.2).

Управління залежностями системи контролю версій в Visual Studio Team System - Розробка і тестування - Програмування - Програмування, исходники, операційні системи

Рис. 6.2 Використання розгалуження


Відображення робочого простору має бути приблизно таким:










Папка в системі контролю версій 


Локальна папка 


 $/MyTeamProject1/Main/Source/


 C:MyTeamProject1MainSource


Структура каталогів робочого простору на боці клієнта повинна бути наступною (рис. 6.3).

Управління залежностями системи контролю версій в Visual Studio Team System - Розробка і тестування - Програмування - Програмування, исходники, операційні системи

Рис. 6.3 Відображення робочого простору на стороні клієнта


Відображення робочого простору


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


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


Наприклад, є два групових проекту, $ MyTeamProject2 і $ Common, і Common містить спільно використовуваний вихідний код. Щоб використовувати загальний код, ці проекти відображені в одну і ту ж структуру каталогів на жорсткому диску клієнта. Структура каталогів робочого простору на боці клієнта повинна бути наступною (рис. 6.4).

Управління залежностями системи контролю версій в Visual Studio Team System - Розробка і тестування - Програмування - Програмування, исходники, операційні системи
Рис. 6.4 Використання відображення робочого простору


Відображення робочого простору повинні бути приблизно такими:













Папка в системі контролю версій 


Локальна папка 


 $/MyTeamProject2/Main/Source/


 C:DevProjectsMyTeamProject2MainSource


 $/Common


 C:DevProjectsMyTeamProject2MainSource Common


Більш докладно читайте в статті “Working with multiple team projects in Team Build” (Як працювати з кількома груповими проектами в Team Build) за адресою http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635. aspx.


Використання збірок сторонніх виробників


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


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


Для груп, що працюють з спільно використовуваними двійковими файлами, доступні ті ж два варіанти, що і при використанні проектів.



Галуження


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


Наприклад, є два групових проекту, $ TeamProject1 і $ Common, і Common містить спільно використовувані виконавчі файли. У проекті, що використовує ці файли, створюється гілка від спільно використовуваного каталогу. Структура каталогів TFS представлена ​​на рис. 6.5.

Управління залежностями системи контролю версій в Visual Studio Team System - Розробка і тестування - Програмування - Програмування, исходники, операційні системи

Рис. 6.5 Галуження від Common


Відображення робочого простору має бути приблизно таким:










Папка в системі контролю версій 


Локальна папка 


 $/MyTeamProject1/Main


 C:MyTeamProject1Main


Структура каталогів робочого простору на боці клієнта представлена ​​на рис. 6.6.

Управління залежностями системи контролю версій в Visual Studio Team System - Розробка і тестування - Програмування - Програмування, исходники, операційні системи
Рис. 6.6 Структура каталогів робочого простору на стороні клієнта


Відображення робочого простору


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


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


Наприклад, є два групових проекту, $ TeamProject2 і $ Common, і TeamProject2 використовує двійкові файли, доступні в Common. Тоді структура каталогів робочого простору на боці клієнта повинна бути наступною (рис. 6.7).

Управління залежностями системи контролю версій в Visual Studio Team System - Розробка і тестування - Програмування - Програмування, исходники, операційні системи

Рис. 6.7 Зберігання спільно використовуваних бібліотек


Відображення робочого простору мають бути такими:













Папка в системі контролю версій 


Локальна папка 


 $/MyTeamProject2/Main/


 C:DevProjectsMyTeamProject2Main


 $/Common/Main/Bin


 C:DevProjectsMyTeamProject2MainSourceCommonBin


Детальніше про це розповідає стаття “Working with multiple team projects in Team Build” за адресою http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx.


Рекомендації по використанню проектів та збірок


Поставити посилання на файл можна двома способами:



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


Переважно використовувати посилання на проекти, а не на файли. При роботі з посиланнями на складання необхідно керуватися наступними рекомендаціями:



Більш детальна інформація представлена ​​в розділі “Рекомендації по роботі з системою контролю версій” даного керівництва.


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


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


Використання Веб-сервісів


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


Для більших систем Веб-сервіси можуть публікуватися на доступному централізованому Веб-сервері. Тоді розробникам не треба локально встановлювати такий Веб-сервіс, так як вони можуть просто звертатися до нього зі своїх клієнтських проектів. Хоча, як обговорюється нижче, необхідно створити відповідне посилання на цей Веб-сервіс.


Більш докладно про це розповідається в розділах “Рекомендації по роботі з системою контролю версій” і “Практики роботи з системою контролю версій” даного керівництва.


Використання динамічних URL для посилання на Веб-сервіси


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


Важливо: Для Веб-сервісів поточного рішення, яке виконується на вашому комп’ютері, повинен використовуватися тільки http://localhost, а не http://MyComputerName. Це гарантує, що посилання залишиться достовірною на всіх комп’ютерах.


Зазвичай в проксі-класі використовується статичний URL. У середовищі виробничої експлуатації або тестування, як правило, необхідний інший URL. Існує три варіанти вирішення цієї проблеми:



При такому підході, з використанням динамічного URL, також з’являється можливість надавати користувальницький конфігураційний файл, який може перевизначати основний конфігураційний файл програми. Це забезпечує можливість окремим розробникам і членам групи тестування тимчасово змінювати посилання на Веб-сервіс.


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


Щоб домогтися максимальної гнучкості конфігурації, як в середовищі розробки, так і в середовищі виробничої експлуатації, властивості URL Behavior посилання на Веб-сервіс має бути задано значення Dynamic. При додаванні Веб-посилання Visual Studio за умовчанням привласнює цій властивості значення Dynamic. Для перевірки значення даної властивості:


1. У Solution Explorer розгорніть список Веб-посилань.


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


3. Для кожної Веб-посилання перевірте значення властивості URL Behavior (воно має бути Dynamic).


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


1. Коли Веб-посилання задається вперше, Visual Studio автоматично створює файл App.config, в якому міститься посилання на Веб-сервіс. Установки конфігурації у файлі App.config виглядають наступним чином:


<configuration>
  <configSections>
    <sectionGroup name=”applicationSettings” type=”System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ >
      <section name=” YourProject.Properties.Settings” type=”System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ requirePermission=”false” />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <YourProject.Properties.Settings>
      <setting name=”SomeService_ localhost _Service” serializeAs=”String”>
        <value>http://localhost/someservice/Service.asmx</value>
      </setting>
      </YourProject.Properties.Settings>
  </applicationSettings>
</configuration>


В даному файлі є нова секція конфігурації, яку використовує створений проксі-клас. У даній секції розташовується адреса Веб-сервісу, виявлений Visual Studio при формуванні цього проксі-класу.


Також Visual Studio поміщає в код, сформований для цього проксі, значення URL за замовчуванням. Це значення знаходиться в файлі Settings.Designer.cs. Щоб побачити цей файл:


1. У Solution Explorer клацніть Веб-сервіс правою кнопкою миші.


2. Виберіть View in Object Browser (Перегляд в браузері об’єктів). У Object Browser знайдіть запис YourProject.Properties, де YourProject – ім’я проекту, що містить посилання на Веб-сервіс.


3. Розгорніть YourProject.Properties і клацніть подвійним клацанням Settings (Настройки). При цьому відкриється файл Settings.Designer.cs, що містить таку рядок:


[global::System.Configuration.DefaultSettingValueAttribute(“http://localhost:/webservice/Service.asmx”)]


Це значення за замовчуванням, використовуване як URL Веб-сервісу, якщо не знайдена інформація про конфігурацію.


Часто виникає необхідність змінити URL викликається Веб-сервісу. Наприклад, потрібно протестувати додаток з використанням Веб-сервісу, що виконується локально на комп’ютері розробника, або версії Веб-сервісу, що виконується в середовищі тестування. Також дуже часто URL Веб-сервісу виробничої експлуатації відрізняється від URL, використовуваного при розробці. Тому значення URL повинно бути задано в користувальницькому файлі конфігурації, на який буде посилатися основний файл App.config. Ім’я користувача конфігураційного файлу вибирається довільно. У наступному прикладі використовується ім’я User.config, щоб було ясно, що це файл з конфігурацією користувача.


Етапи створення файлу User.config:


1. У Solution Explorer клацніть правою кнопкою миші проект, що містить посилання на Веб-сервіс, виберіть Add і потім клацніть New Item (Новий елемент).


2. Виберіть Application Configuration File (Конфігураційний файл програми), змініть ім’я на User.config і клацніть Add.


3. Скопіюйте налаштування елемента з конфігураційного файлу додатки (App.config) в файл User.config. Цей файл повинен містити тільки елемент, який виноситься з основного конфігураційного файлу програми. Видаліть директиву і елемент , якщо вони присутні, як показано в наступному прикладі


<YourProject.Properties.Settings>
  <setting name=”SomeService_localhost_Service” serializeAs=”String”>
    <value>http://localhost/someservice/Service.asmx</value>
  </setting>
</YourProject.Properties.Settings>


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


1. Додайте атрибут configSource = “user.config” в елемент головного конфігураційного файлу програми. Тим самим, отримавши інформацію з цієї секції, середа виконання буде перенаправлена ​​в зазначений користувальницький конфігураційний файл.


2. Видаліть вміст елемента .


Тепер App.config повинен виглядати наступним чином:


<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
  <configSections>
    <sectionGroup name=”applicationSettings” type=”System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ >
      <section name=”YourProject.Properties.Settings” type=”System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ requirePermission=”false” />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <yourProject.Properties.Settings configSource=”user.config”>
      </YourProject.Properties.Settings>
    </applicationSettings>
</configuration>


У попередньому прикладі YourProject – Ім’я проекту, що містить посилання на Веб-сервіс.


Важливо: Якщо використовується атрибут configSource, Користувальницький конфігураційний файл повинен бути присутнім і містити лише один елемент, . Також необхідно гарантовано видалити XML-вміст елемента при додаванні атрибута configSource=”user.config”.


При використанні User.config:



Підказка: За замовчуванням користувальницький конфігураційний файл автоматично додається в систему контролю версій при додаванні рішення. Щоб запобігти цьому, при першій реєстрації змін у файлі необхідно прибрати прапорець навпроти файлу User.config. Після цього можна натиснути правою кнопкою миші файл в Solution Explorer і вибрати опцію Undo Pending Changes (Скасувати очікують реєстрації зміни). Тоді файл гарантовано не буде підлягати контролю версій.


Важливо: Якщо у файлі User.config, задаючому URL, є тільки кореневий елемент, і немає елемента налаштувань, проксі-клас Веб-сервісу використовує URL за замовчуванням, який вказаний у файлі Settings.Designer.cs. Це значення визначене як атрибут DefaultValueSettings (Значення за замовчуванням) і виглядає наступним чином


[global::System.Configuration.DefaultSettingValueAttribute(“http://localhost/webservice/Service.asmx”)]


Важливо: Для Веб-додатків, що використовують для користувача конфігураційний файл, будь-які зміни цього файлу за замовчуванням призводять до автоматичного перезапуску Веб-додатки. Щоб скасувати перезапуск програми при зміні значення, необхідно додати атрибут restartOnExternalChanges = “false” (перезапустити при зовнішніх змін) в опис секції конфігураційного файлу, як це зроблено нижче:


<configSections>
  <sectionGroup name=”applicationSettings” type=”System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″>
    <section name=”Test.Properties.Settings” type=”System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ requirePermission=”false” restartOnExternalChanges=”true”/>
  </sectionGroup>
</configSections>


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


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


Використання баз даних


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


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


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


Як використовувати користувальницький конфігураційний файл при роботі з рядками з’єднань з базами даних


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


Щоб використовувати конфігураційний файл користувача для зберігання рядків з’єднання з базою даних:


1. Додайте атрибут configSource=”user.config” в елемент головного конфігураційного файлу програми.


<configuration>
  <connectionStrings configSource=”user.config”/>
</configuration>


2. Щоб перевизначити головний конфігураційний файл програми, створіть файл User.config (розташувавши його в тій же папці, що і конфігураційний файл програми) і потім додайте таку ж запис в цей файл. Зверніть увагу на те, що наступна рядок з’єднання посилається на локальну базу даних.


<connectionStrings>
  <add name=”DBConnStr” connectionString=”server=localhost;Integrated Security=SSPI;database=Accounts”/>
</connectionStrings>


3. У своєму проекті застосовуйте наступний код для отримання рядка з’єднання з користувацького конфігураційного файлу.


using System.Configuration;


private string GetDBaseConnectionString()
{
    return ConfigurationManager.ConnectionStrings[“DBConnStr”].ConnectionString;
}


У цьому коді використовується статичне властивість ConnectionStrings (Рядки з’єднання) класу System.Configuration.ConfigurationManager. У додатках WinForm необхідно додати явну посилання на System.Configuration.dll.


4. Переконайтеся, що файл User.config розгортається разом з кодом програми. Для цього в Solution Explorer клацніть правою кнопкою миші файл User.config, виберіть Properties і потім у вікні Properties задайте властивості Copy To Output Directory значення Copy if newer.


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


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


Зауваження: За замовчуванням користувальницький конфігураційний файл автоматично додається в систему контролю версій при додаванні рішення. Щоб запобігти цьому, при першій реєстрації змін у файлі необхідно прибрати прапорець навпроти файлу User.config. Після цього можна натиснути правою кнопкою миші файл в Solution Explorer і вибрати опцію Undo Pending Changes. Тоді файл гарантовано не буде підлягати контролю версій.


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


Висновок


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


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


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

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


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

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

Ваш отзыв

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

*

*