Управление файлами web.config

Question

У меня есть 3 среды: Dev, QA, Prod на .NET 4. Каждая имеет уникальный файл web.config.У нас были проблемы с управлением всеми тремя версиями.Его легко упустить из виду, когда вы вручную объединяете файлы web.config в TFS.Мы неоднократно получали строку подключения, указывающую на QA в Prod.

Итак, Я прочитал преобразования web.config. Похоже, что для этого требуется MSBUILD.У нас нет сервера сборки, поэтому я не уверен, как я могу попытаться использовать это решение.Есть ли способ заставить преобразования работать с обычной веб-публикацией?

Есть ли у вас какие-либо альтернативные предложения по управлению 3 файлами web.config?

Answer 1

Если вы используете проект websetup для создания msi, вы можете добавить собственный класс установщика в websetup.Это даст вам возможность создавать предопределенные пакетные сценарии, которые будут правильно устанавливать значения в web.config

msiexec.exe /Qb! /i "MyWebsiteMsi.MSI" SQL_SERVER_ConnStr="ABC" 

Вот некоторая страница со старым примером введите описание ссылки здесь

Answer 2

Есть ли способ сделать преобразования работать с обычной веб-публикацией?

Абсолютно, взгляните на эту ссылку MSDN . Вам не нужен MSBUILD. Вы можете установить строки подключения для различных сред в отдельных конфигурационных файлах. Например, у вас могут быть Web.config, Web.QA.config и Web.Prod.config, где QA и Prod являются отдельными конфигурациями Visual Studio Build .

В качестве альтернативы вы можете просто использовать конфигурации сборки, которые добавляются по умолчанию: Web.config (локальная разработка), Web.Debug.config (используется для QA) и Web.Release.config (используется для производства).

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

После настройки ваших конфигураций и преобразований вы просто меняете конфигурацию сборки, собираете и публикуете ее из Visual Studio.

Answer 3

Есть ли у вас какие-либо альтернативные предложения по управлению 3 файлами web.config?

Да, не управляйте ими.Чем меньше нам удается, тем меньше шансов ошибиться.Иметь одинаковые файлы web.config для всех ваших сред.Один и тот же дистрибутивный пакет развернут везде.

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

Answer 4

Альтернативой является создание перемещения ваших настроек, которые изменяются во внешний файл, и ссылка на этот файл обратно с использованием атрибута configSource.Для разделов, которые отличаются, вы помещаете это во внешний файл.

Затем вы можете либо иметь отдельно названные файлы, например, dev.config, qa.config, live.config и изменить имя в web.config, либоу вас есть 1 файл с именем environment.config, и вы никогда не объединяете его между средами.

Недостатком является то, что весь раздел настроек должен быть перемещен в файл.

Simon