Как Вы имеете дело со строками подключения при развертывании сайта ASP.NET?

Используйте веб-Проект Развертывания и обновите wdproj файл (это - просто файл MSBuild) с некоторыми задачами сборки сообщения произвести корректный .config файл. Я сохраняю web.config, и web.release.config затем используют это в wdproj файле:

<Target Name="AfterBuild">
    <Copy Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\web.release.config" DestinationFiles="$(OutputPath)\web.config" />
    <Delete Files="$(OutputPath)\web.release.config" />
</Target>

Больше информации

Простое решение, которое некоторые любят, использует configSource свойство appSettings и connectionStrings и затем никогда не перезаписывает тот файл на рабочем сервере.

У меня обычно есть три отдельных веб-конфигурации: один для моей машины разработки, один для QA, и один для производства. Разработка, которую каждый подключает к моей локальной базе данных SQL (который является firewalled снаружи) и это - значение по умолчанию web.config. Другие называют сетью-prod.config и сетью-qa.config. После публикации я удаляю два, что я не нуждаюсь и переименовываю корректный к web.config. Если я забываю, приложение повреждается в первый раз, когда оно пытается получить доступ к базе данных, так как конфигурация по умолчанию ссылается на тот, до которого это не может добраться.

Так как IIS отказывается подавать файл, названный .config, я удостоверяюсь, что они все заканчивают в .config вместо, говорят web.config-напоминание или web.config-обеспечение-качества.

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

Для SQL Server перейдите к Менеджеру конфигурации SQL Server> Собственная Клиентская Конфигурация SQL>, Псевдонимы> Создают Новый Псевдоним.

Можно сделать то же самое с Oracle с tnsnames файлом.

Вот другая вещь, которую можно попробовать:

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

Я делал это так часто, я сделал web.config на рабочем сервере только для чтения.

имейте папки среды с отдельными конфигурациями для каждой среды

разверните корректный для среды

Мы управляем нашим развертывание с нашего сервера CI. Мы обычно имеем отдельный файл для каждого местоположения и имеем переключатель сервера CI к соответствующей конфигурации в зависимости от переданного ot аргументов это. Все редактирование файла сделано в сценариях NAnt, поэтому разрабатывает, может работать, sam основываются на своей машине для получения их собственных настроек.

Я был в нескольких местах теперь, когда хранят их в реестре.

Существуют, вероятно, более тщательно продуманные способы сделать это теперь, но много кода, я продолжил работать с 1.0/1.1 наследием, хранит строки в реестре.

Реестр имеет несколько преимуществ

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

Я помещу свои строки подключения в machine.config на наших полях QA и Production. Я сохраню их в web.config на моем dev поле для гибкости, все же. Затем я буду использовать веб-проект развертывания перезаписать мои dev строки подключения ни с чем (никакие строки подключения) при развертывании к QA. Поэтому сайт QA полагается на строки подключения в machine.config. Я все еще развертываюсь к Производству вручную, чтобы удостовериться, что все успешно выполняется. Я делаю это путем ручного копирования всего с QA (за исключением web.config) к производству.

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

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

Вкратце: существует только один web.config в управлении исходным кодом, и это - настройка разработки (отладка дружественный, локальный дб, и т.д.). Сервер сборки делает компиляцию, затем развертывание на канареечном сайте, затем пакет для предвыпускной версии.

Мы используем nant, таким образом, это - .build файл, который имеет xmlpoke, чтобы установить отладку = "ложь", изменить строки подключения, и безотносительно потребностей измениться в канареечной копии и упаковочной копии web.config.

Машина сборки развертывается, назван "канарейкой", потому что это - первая вещь умереть, если существует проблема.