В данной статье рассматривается, как следует обрабатывать зависимости внутри и между решениями Visual Studio. Единый подход к управлению зависимостями в среде коллективной разработки необходим для обеспечения стабильности процесса сборки и сокращения текущих затрат на обслуживание системы контроля версий. Зависимости - это другие проекты, внешние сборки, Веб-сервисы и базы данных. Зависимости неизбежно меняются во времени и, в результате, оказывают влияние на процесс и порядок сборки приложения. Соответствующий подход к управлению зависимостями способствует улучшению и упрощению процесса интеграции.
Как использовать данную статью
Данная статья рассказывает об управлении зависимостями в среде коллективной разработки. Ее можно прочитать от начала и до конца или ознакомиться лишь с разделом, рассматривающим конкретный вопрос управления зависимостями. Раздел "Сценарии и решения" поможет понять, какие вообще сценарии управления зависимостями существуют в среде коллективной разработки. Этот раздел является трамплином для перехода к следующим разделам, подробно рассматривающим каждый из сценариев.
- Раздел "Использование проектов" рассказывает о том, как работать со ссылками на другие проекты, как внутренними, так и внешними по отношению к текущему групповому проекту.
- Раздел "Использование сборок сторонних производителей" рассказывает, как работать со ссылками на сборки сторонних производителей, исходным кодом которых вы не располагаете.
- Раздел "Использование Веб-сервисов" рассказывает, как работать со ссылками на совместно используемые Веб-сервисы в среде коллективной разработки.
- Раздел "Использование баз данных" рассказывает, как соединяться с базами данных и использовать их в среде коллективной разработки.
Сценарии и решения
Обычно реализуются следующие сценарии управления зависимостями:
1. Используется сборка, сформированная другим проектом в том же решении.
2. Используется сборка, сформированная другим проектом в другом решении.
3. Используется сборка из другого группового проекта.
4. Используется сборка стороннего производителя.
Использование сборок, сформированных другим проектом в том же решении
Если требуется включить сборку из этого же решения Visual Studio, используется ссылка на проект Visual Studio. В случае применения ссылок на проекты Visual Studio может автоматически выполнять некоторые действия, например, обеспечивать синхронизацию конфигурации сборки (отладка/версия для выпуска), отслеживать версии и повторно выполнять сборку компонентов при изменении версий сборок.
Использование сборок, сформированных проектами других решений
Существует два варианта использования сборки, сформированной проектом в другом решении Visual Studio:
- Использовать ссылку на двоичный файл сборки.
- Добавить проект Visual Studio (файлы проектов и исходные файлы) в решение и затем использовать ссылку на проект.
Ссылки на файлы более уязвимы, чем ссылки на проекты, так как они не синхронизируются с конфигурацией сборки и не отслеживаются Visual Studio. Поэтому при изменении используемых сборок Visual Studio не знает о том, что необходимо выполнить сборку повторно.
В качестве альтернативного варианта можно создать ветвь для внешнего проекта в текущем решении, скомпилировать двоичный файл и затем использовать ссылку на проект. Эта ссылка будет более устойчивой, хотя придется регулярно производить синхронизацию с исходной ветвью проекта и переносить все вносимые в нее изменения.
Использование сборки из другого группового проекта
При совместном использовании исходного кода или двоичных файлов в групповых проектах возможны два варианта:
- Ветвление. При таком подходе в текущее решение добавляется ветвь исходного кода из другого группового проекта. Таким образом, создается конфигурация, объединяющая на стороне сервера совместно используемый исходный код и исходный код текущего проекта.
- Отображение рабочего пространства. При таком подходе исходный код другого группового проекта отображается в рабочем пространстве разработчика. Таким образом, создается конфигурация, объединяющая на стороне клиента исходный код другого группового проекта и текущий проект.
Предпочтительнее использовать ветвление, потому что в этом случае зависимости сохраняются на сервере системы контроля версий. Отображение рабочего пространства происходит только на стороне клиента, т.е. чтобы обеспечить успешную сборку приложения, каждый разработчик должен создавать отображение, как на своем компьютере, так и на сервере сборки.
При ветвлении возникают дополнительные издержки на слияние, они влияют на решение, использовать ли обновления в виде бинарных файлов или в виде исходного кода.
Использование сборки стороннего производителя
Этот сценарий очень похож на использование других групповых проектов, только в данном случае совместно используются только двоичные файлы, а не исходный код. Перед нами возникает тот же выбор между ветвлением и рабочими пространствами, только дополнительные издержки в данном случае, скорее всего, будут ниже, потому что сборки сторонних производителей меняются не так часто.
Использование проектов
Например, имеется групповой проект Visual Studio, содержащий совместно используемый несколькими групповыми проектами код библиотеки. Можно сохранять проект в рамках исходного группового проекта или создать отдельный групповой проект специально для совместно используемого проекта. Для второго варианта, когда создается общий совместно используемый проект, структура каталогов системы контроля версий Microsoft Visual Studio Team Foundation Server (TFS) следующая (рис. 6.1).
Рис. 6.1 Структура каталогов при общем совместно используемом проекте
Существует два варианта совместного использования проекта из собственного группового проекта
- Ветвление
- Отображение рабочего пространства
Ветвление
В сценариях совместного использования исходного кода предпочтительнее остановиться на ветвлении. Это позволяет перенести совместно используемый исходный код в разрабатываемый проект и зарегистрировать его в системе контроля версий группового проекта. В этом сценарии создается ответвление версии исходного кода из совместно используемого каталога в групповом проекте. При этом возникает конфигурация, объединяющая на стороне сервера исходный код из совместно используемого каталога и разрабатываемого проекта.
Изменения совместно используемого исходного кода распространяются в ходе процесса слияния ветвей. При этом решение о распространении изменений в совместно используемом исходном коде становится более явным, его проще тестировать, но также возникают некоторые дополнительные издержки. Кроме того, в этом случае существенно упрощается использование Team Build, поскольку отображение выполняется на стороне сервера; нет отображения на стороне клиента, которое должно дублироваться на сервере сборки.
Например, имеется два групповых проекта, $TeamProject1 и $Common, и Common содержит совместно используемый исходный код. Тогда в проекте, использующем
Common, создается ответвление совместно используемого каталога. Получаем следующую структуру каталогов TFS (рис. 6.2).
Рис. 6.2 Использование ветвления
Отображение рабочего пространства должно быть примерно следующим:
|
Папка в системе контроля версий |
Локальная папка |
|
$/MyTeamProject1/Main/Source/ |
C:\MyTeamProject1\Main\Source |
Структура каталогов рабочего пространства на стороне клиента должна быть следующей (рис. 6.3).
Рис. 6.3 Отображение рабочего пространства на стороне клиента
Отображение рабочего пространства
Если вы хотите, чтобы любые изменения совместно используемого кода сразу же поступали к разработчикам, т.е. избежать издержек на ветвление и слияние, можно создать отображение совместно используемого исходного кода общего проекта в рабочем пространстве разработчика. При этом создается конфигурация, которая объединяет исходный код из совместно используемого каталога с разрабатываемым проектом на стороне клиента.
Преимущество этого подхода в том, что все изменения совместно используемого проекта поступают в рабочее пространство разработчика при каждой загрузке последней версии исходного кода. Однако это затрудняет использование Team Build, поскольку отображение рабочего пространства является структурой на стороне клиента.
Например, имеется два групповых проекта, $MyTeamProject2 и $Common, и Common содержит совместно используемый исходный код. Чтобы использовать общий код, эти проекты отображены в одну и ту же структуру каталогов на жестком диске клиента. Структура каталогов рабочего пространства на стороне клиента должна быть следующей (рис. 6.4).
Рис. 6.4 Использование отображения рабочего пространства
Отображения рабочего пространства должны быть примерно следующими:
|
Папка в системе контроля версий |
Локальная папка |
|
$/MyTeamProject2/Main/Source/ |
C:\DevProjects\MyTeamProject2\Main\Source\ |
|
$/Common |
C:\DevProjects\MyTeamProject2\Main\Source\ 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.
Рис. 6.5 Ветвление от Common
Отображение рабочего пространства должно быть примерно следующим:
|
Папка в системе контроля версий |
Локальная папка |
|
$/MyTeamProject1/Main |
C:\MyTeamProject1\Main |
Структура каталогов рабочего пространства на стороне клиента представлена на рис. 6.6.
Рис. 6.6 Структура каталогов рабочего пространства на стороне клиента
Отображение рабочего пространства
Если групповой проект совместно использует двоичные файлы, то они отображаются из совместно используемого каталога в рабочее пространство разработчика на его компьютере. В этом случае возникает конфигурация, объединяющая на стороне клиента двоичные файлы из совместно используемого каталога и разрабатываемый проект.
Преимущество этого подхода в том, что изменения в совместно используемых двоичных файлах поступают в рабочее пространство разработчика при каждой загрузке последней версии исходного кода.
Например, имеются два групповых проекта, $TeamProject2 и $Common, и TeamProject2 использует двоичные файлы, доступные в Common. Тогда структура каталогов рабочего пространства на стороне клиента должна быть следующей (рис. 6.7).
Рис. 6.7 Хранение совместно используемых библиотек
Отображения рабочего пространства должны быть такими:
|
Папка в системе контроля версий |
Локальная папка |
|
$/MyTeamProject2/Main/ |
C:\DevProjects\MyTeamProject2\Main\ |
|
$/Common/Main/Bin |
C:\DevProjects\MyTeamProject2\Main\Source\CommonBin |
Подробнее об этом рассказывает статья "Working with multiple team projects in Team Build" по адресу http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx.
Рекомендации по использованию проектов и сборок
Задать ссылку на файл можно двумя способами:
- Чтобы сослаться на сборку .NET Framework, необходимо выбрать ее из списка, отображаемого на вкладке .NET диалогового окна Add References (добавить ссылки).
- Используйте кнопку Browse (Просмотр) диалогового окна Add Reference.
Сборки, такие как System.XML.dll, располагаются в Глобальном кэше сборок (Global Assembly Cache, GAC). Однако мы никогда не ссылаемся на сборку в GAC напрямую. При выборе сборки на вкладке .NET диалогового окна Add References на самом деле происходит ссылка на копию сборки, находящуюся в папке %windir%\Microsoft.NET\Framework\<version>\.
Предпочтительнее использовать ссылки на проекты, а не на файлы. При работе со ссылками на сборки необходимо руководствоваться следующими рекомендациями:
- Везде, где это возможно, использовать ссылки на проекты.
- Использовать ссылки на файлы только по необходимости.
- Для ссылок на проекты и файлы использовать Copy Local = True.
Более подробная информация представлена в разделе "Рекомендации по работе с системой контроля версий" данного руководства.
Автоматическое отслеживание зависимостей
При каждой сборке локального проекта система сборки сравнивает дату и время файла сборки, на которую ссылается проект, с используемой рабочей копией этого файла на компьютере разработчика. Если версия по ссылке более свежая, чем рабочая копия, в локальную папку копируется новая версия. Одно из преимуществ такого подхода состоит в том, что ссылка на проект, созданная разработчиком, не блокирует динамически подключаемую библиотеку (DLL) сборки на сервере и никак не вредит процессу сборки.
Использование Веб-сервисов
В более простых системах, в которых все проекты системы располагаются в одном групповом проекте, все разработчики, в конце концов, работают с локальными рабочими копиями всех Веб-сервисов, потому что они определены проектами Visual Studio в групповом проекте. Все проекты (включая все Веб-сервисы) устанавливаются локально при первом открытии решения из системы контроля версий. Аналогично, если Веб-сервис добавляется в решение одним из разработчиков, у всех остальных он устанавливается при следующем обновлении. При таком сценарии нет необходимости публиковать Веб-сервисы на центральном Веб-сервере среды коллективной разработки.
Для более крупных систем Веб-сервисы могут публиковаться на доступном централизованном Веб-сервере. Тогда разработчикам не надо локально устанавливать такой Веб-сервис, так как они могут просто обращаться к нему из своих клиентских проектов. Хотя, как обсуждается ниже, необходимо создать соответствующую ссылку на этот Веб-сервис.
Более подробно об этом рассказывается в разделах "Рекомендации по работе с системой контроля версий" и "Практики работы с системой контроля версий" данного руководства.
Использование динамических URL для ссылки на Веб-сервисы
Если требуется вызвать Веб-сервис, необходимо сначала добавить в проект Веб-ссылку. При этом создается прокси-класс, посредством которого осуществляется взаимодействие с Веб-сервисом. Код прокси-класса изначально содержит статический Универсальный указатель ресурса (Uniform Resource Locator, URL) Веб-сервиса, например, http://localhost или http://SomeWebServer.
Важно: Для Веб-сервисов текущего решения, которое выполняется на вашем компьютере, должен использоваться только http://localhost, а не http://MyComputerName. Это гарантирует, что ссылка останется достоверной на всех компьютерах.
Обычно в прокси-классе используется статический URL. В среде производственной эксплуатации или тестирования, как правило, необходим другой URL. Существует три варианта решения этой проблемы:
- Можно задавать URL Веб-сервиса программно при создании экземпляра прокси-класса.
- Более гибкий подход без жесткого кодирования URL в прокси-классе - задать свойству URL Behavior (Поведение URL) ссылки на Веб-сервис значение Dynamic (Динамический). Такой подход является предпочтительным. Когда этому свойству задается значение Dynamic, в прокси-класс добавляется код для извлечения URL Веб-сервиса из специальной секции конфигурационного файла приложения (Web.config для Веб-приложения или SomeApp.exe.config для приложения Windows).
- Также можно создать прокси-класс с помощью инструмента командной строки WSDL.exe, задавая ключ /urlkey. При этом подобно заданию значения свойства URL Behavior, в прокси добавляется код для извлечения URL Веб-сервиса, только в этом случае URL хранится в секции <applicationSettings> конфигурационного файла приложения.
При таком подходе, с использованием динамического 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. Скопируйте настройки элемента <YourProject.Properties.Settings> из конфигурационного файла приложения (App.config) в файл User.config. Этот файл должен содержать только элемент, который выносится из основного конфигурационного файла приложения. Удалите директиву <?xml> и элемент <configuration>, если они присутствуют, как показано в следующем примере
<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" в элемент <YourProject.Properties.Settings> главного конфигурационного файла приложения. Тем самым, получив информацию из этой секции, среда выполнения будет перенаправлена в указанный пользовательский конфигурационный файл.
2. Удалите содержимое элемента <YourProject.Properties.Settings>.
Теперь 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, пользовательский конфигурационный файл должен присутствовать и содержать всего один элемент, <YourProject.Properties.Service>. Также необходимо гарантированно удалить XML-содержимое элемента <YourProject.Properties.Service> при добавлении атрибута configSource="user.config".
При использовании User.config:
- Убедитесь, что развертывание файла User.config происходит вместе с кодом приложения. Для этого в Solution Explorer щелкните правой кнопкой мыши файл User.config, выберите опцию Properties и задайте свойству Copy To Output Directory (Копировать в выходной каталог) значение Copy if newer (Копировать, если это более свежая версия).
- Не добавляйте свой файл User.config в систему контроля версий. Так каждый разработчик и группа тестирования могут явно привязываться к определенным URL, используя собственные файлы User.config. В системе контроля версий могут располагаться другие файлы User.config, например, используемые для тестирования и производственной эксплуатации. Эти файлы должны обслуживаться пользователями, ответственными за управление средами тестирования и производственной эксплуатации. Файлы User.config для тестирования и производственной эксплуатации не должны храниться как часть проектов Веб-сервиса, они должны располагаться в других областях системы контроля версий.
- Храните глобальный файл User.config в системе контроля версий. Он может содержать только корневой элемент (без элемента <setting>) или может определять местоположение Веб-сервиса по умолчанию. Наличие файла 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" в элемент <connectionStrings> главного конфигурационного файла приложения.
<configuration>
<connectionStrings configSource="user.config"/>
</configuration>
2. Чтобы переопределить главный конфигурационный файл приложения, создайте файл User.config (расположив его в той же папке, что и конфигурационный файл приложения) и затем добавьте такую же запись <connectionStrings>в этот файл. Обратите внимание на то, что следующая строка соединения ссылается на локальную базу данных.
<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.