Разработка против производства: Строки подключения - PullRequest
5 голосов
/ 04 февраля 2009

Я в процессе перемещения сервера SQL на отдельную машину. В настоящее время мы используем наш веб-сервер и сервер sql на одном компьютере. Итак, у нас есть рабочий сервер с IIS и SQLServer, а затем отдельный сервер разработки, который отражает эту настройку.

Когда дело доходит до app.config нашего элемента управления asp.net и web.config веб-сайта, это работает хорошо, потому что мы могли использовать «Initial Catalog = MyDB; ...», и это работало, потому что имя БД было одинаковым на обеих машинах.

Теперь я смотрю на запуск обеих БД на одном компьютере (MyDB, MyDB-Dev). Есть ли простой способ сделать это без необходимости редактировать web.config и app.config каждый раз, когда мы разворачиваем или компилируем? Может ли Visual Source Safe с этим справиться?

Ответы [ 8 ]

7 голосов
/ 04 февраля 2009

Вот решение, которое я использую. В файле Web.Config поместите следующую строку «include»:

<connectionStrings configSource="WebCS.config"/>

Затем создайте файл WebCS.config и введите следующее:

<connectionStrings>
<add name="ConnString" 
     connectionString="Data Source=YourServer;Initial Catalog=YourDB;etc..
     providerName="System.Data.SqlClient"/>
</connectionStrings>

Затем, после публикации вашего сайта в VS, удалите файл WebCS.config (у меня есть пакетный файл для этого), прежде чем объединить все остальное для передачи на новый компьютер. После этого вы будете уверены, что все настройки файла Web.Config будут сохранены без вмешательства в строку подключения.

4 голосов
/ 04 февраля 2009

Развертывание web.config почти никогда не копирует файл из dev в prod. Нормально иметь разные записи, например ваш веб-сайт разработчика указывает на локальную базу данных или блок базы данных разработчиков, а ваш веб-сайт prod обычно должен указывать на ваш блок базы данных prod.

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

При управлении исходным кодом обычной практикой является исключение web.config и наличие файла шаблона, который можно использовать в качестве основы для создания файла конфигурации, например, web.config.template. При внесении структурных изменений в web.config вы должны внести изменения в web.config.template, затем сделать его копии для dev и prod и соответственно применить настройки dev и prod.

2 голосов
/ 04 февраля 2009

Я использую NAnt для сборки и развертывания. Я превращаю свои файлы .config в шаблоны, используя соглашение об именах .config.template. У меня есть свойство NAnt с именем «environment», которое я устанавливаю из вызова командной строки для NAnt. В верхней части моего build.xml я установил свойство "db.connectionstring" на основе свойства "environment" (например, оператора switch). В задаче сборки я использую grep, чтобы вставить строку «db.connectionstring» в место в шаблоне для вывода каталога сборки. Таким образом, мне нужно только позвонить:

nant -D:environment=dev

Получает набор файлов .config для конкретного разработчика.

Если вам не нравится grep, следуйте этому:

http://www.haidongji.com/2008/11/11/use-nant-to-replace-values-in-other-xml-config-files/

Это работает только для файлов XML. Grep более общий. На самом деле у меня разные имена баз данных в зависимости от среды развертывания, и grep позволяет мне вставлять разные имена баз данных в сценарии SQL в зависимости от среды.

1 голос
/ 04 февраля 2009

Возможно, я не совсем понимаю ваш вопрос здесь, но мне кажется, что при развертывании приложения вы просто не можете повторно развернуть web.config, если в файле web.config не нужно вносить изменения. Другими словами, скопируйте все файлы в каталог , кроме файла web.config.

Если вам нужно изменить файл web.config между развертываниями, вам нужно будет отредактировать файл web.config для каждого сервера.

В качестве альтернативы вы можете найти другое место на каждом компьютере для хранения строк подключения, отличных от web.config.

0 голосов
/ 31 августа 2017

Для разработки используйте файл Web.Debug.config, а для разработки используйте Web.Release.config. Каждый может определить свою собственную отдельную строку подключения.

0 голосов
/ 08 февраля 2009

Можете ли вы поместить все строки подключения в файл web.config, а затем в главном пункте приложения определить, какой из них использовать, на основе сервера приложений?

0 голосов
/ 05 февраля 2009

Просто, чтобы я понял, ваша текущая среда состоит из двух серверов, то есть

Сервер приложений / БД Dev
Производственное приложение / сервер БД

и ты думаешь сделать что-то вроде этого

Сервер приложений (dev + production)
БД Сервер (dev + production)

Если это так, я рекомендую вам изолировать БД и приложение на двух отдельных серверах - при переходе из среды с одним сервером это первый шаг, поскольку он позволяет легко выполнить обновление позже, если вам нужно кластеризовать несколько серверов БД или (чаще) балансировка нагрузки нескольких веб-серверов перед одним сервером БД для повышения производительности приложений.

Сказав это, я не предлагаю запускать разработчики и производственные среды бок о бок на одном и том же сервере. Хотя это может иметь смысл с финансовой точки зрения, цель изолированной среды разработки состоит в том, чтобы не допустить утечки ошибок разработки в производство, и подобное может привести к простоям, если у вас есть какой-то плохой код, который передается в среду разработки.

0 голосов
/ 04 февраля 2009

проверьте атрибут configSource элемента connectionStrings в файле web.config

это должно сделать это достаточно просто

...