Разработка по сравнению с производством: строки подключения
Поскольку вы проявили интерес к рекурсивному методу, вот что нужно учитывать. Нажатие на желтые детали уценки показывает спойлеры.
function f(str, sub, i=0, j=0){
if (j && j == sub.length)
return true;if (i == str.length)[112 ]
return false;
i+1, j+1);return f(str, sub,
i+1, 0);}
7 ответов
Вот решение, которое я использую. В сети. Конфигурация, поместите, следующее "включают" строку:
<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 почти никогда не является случаем копирования файла от dev для подталкивания. Нормально иметь отличающиеся записи, например, Ваш dev веб-сайт указывает на локальную базу данных или dev поле базы данных, и Ваш веб-сайт напоминания обычно должен указывать на Ваше поле базы данных напоминания.
При развертывании производство web.config обычно только должно быть изменено при создании изменений в архитектуре в приложении, которые требуют новых элементов конфигурации, или Вы хотите удалить избыточные.
С управлением исходным кодом обычная практика должна исключить web.config и иметь шаблонный файл, который может использоваться в качестве основания для создания файла конфигурации, например, web.config.template. При внесении структурных изменений в web.config необходимо внести изменения в web.config.template, затем сделать копии из него для dev и напоминания, и применить dev и подталкивать настройки соответственно.
Я использую NAnt, чтобы создать и развернуться. Я превращаю свои .config файлы в шаблоны с помощью .config.template соглашения о присвоении имен. У меня есть свойство NAnt, названное "средой", которую я установил от вызова командной строки до NAnt. Наверху моего build.xml я установил "db.connectionstring" свойство на основе свойства "среды" (как оператор переключения). В задаче сборки я использую grep для продвижения строки "db.connectionstring" в пятно в шаблоне для вывода каталога сборки. Тем путем я только должен звонить:
nant -D:environment=dev
Это получает dev-определенный набор .config файлов.
Если Вы не любите grep, следуете за этим:
http://www.haidongji.com/2008/11/11/use-nant-to-replace-values-in-other-xml-config-files/
Это только работает на XML-файлы. Grep более универсален. У меня на самом деле есть различные имена базы данных на основе среды развертывания, и grep позволяет мне вставить различные имена базы данных в сценарии SQL на основе среды.
Я не могу полностью понять Ваш вопрос здесь, но мне кажется, что при развертывании приложения Вы не можете просто повторно развернуть web.config, если нет изменения в web.config, который должен быть сделан. Другими словами, скопируйте все файлы в каталог кроме web.config файла.
Если действительно необходимо изменить web.config файл между развертыванием, необходимо будет отредактировать web.config для каждого сервера.
С другой стороны, Вы могли найти, что другое место на каждой машине сохранило строки подключения кроме web.config.
проверьте configSource атрибут connectionStrings элемента в web.config
это должно помочь достаточно
Можно ли поместить все строки соединений в web.config, и затем в основном моменте в приложении определяют который использовать на основе сервера приложений?
Именно так я ясен, Ваша текущая среда является двумя серверами, т.е.
Dev приложение/сервер БД
Производственное приложение / СЕРВЕР БД
и Вы думаете о создании его что-то вроде этого
Сервер приложений (dev+production)
Сервер БД (dev+production)
Если это так, я рекомендую Вас для изоляции DB и приложения в два отдельных сервера - при перемещении от единственной серверной среды, это - первый шаг, поскольку это допускает простое обновление позже, если необходимо кластеризировать несколько серверов БД или (чаще всего) загружаться, балансируют несколько веб-серверов перед единственным сервером БД для помощи производительности приложения.
Однако я не предлагаю выполнить dev и продуктивные среды рядом как это на том же сервере. В то время как это может иметь смысл в финансовом отношении, цель изолированной dev среды состоит в том, чтобы помешать 'dev ошибкам' выходить за край в производство, и сделать это как это может привести ко времени простоя, если у Вас есть некоторый плохой код, который продвинут к dev среде.