Как управлять несколькими файлами web.config в проекте веб-сайта ASP.NET?

Я провел последние несколько часов в поисках лучшего решения растущей проблемы:

  • У нас появляется все больше и больше веб-сайтов (в VS 2010) и, следовательно, все больше и больше файлов web.config для управления. Между средами dev и prod довольно много различий (строки подключения, конфигурация трассировки/отправки по электронной почте и т. д.).
  • Кроме того, в зависимости от команды, с которой кто-то работает (например, команда веб-дизайна), он не может иметь доступ к некоторым паролям и ключам шифрования (находящимся в файле web.config).

В настоящее время у нас есть:

  • Файл web.config, содержащий значения prod (строки подключения, пароли).
  • Файл web.config.dev, содержащий значения dev.
  • Файл web.config.restricted, содержащий минимальные необходимые значения, позволяющие веб-дизайнерам выполнять свою работу.

Следовательно:

  • Каждый раз, когда разработчик хочет добавить новую строку в файл web.config, ему также необходимо вставить эту строку в файл web.config.dev (и, в конечном итоге, в файл web.config.restricted).
  • After check in:
    • all the members of the dev team have to copy all the content from the web.config.dev file and override their web.config file.
    • все члены группы веб-дизайна должны скопировать все содержимое из файла web.config.restricted и переопределить свой файл web.config.
  • Эти ручные операции вызывают массу ошибок (люди забывают отразить изменения во всех файлах).
  • TFS должна быть настроена так, чтобы не предоставлять доступ к файлу web.config группе веб-дизайнеров (они должны создать файл вручную).

Я смотрю на менее хакерские способ:

  • Управляйте несколькими средами (dev/prod) без дублирования всего содержимого файла web.config.
  • Управляйте правами TFS, чтобы скрыть некоторые конфиденциальные значения для определенных команд.

Обратите внимание, что:

  • Я использую проекты веб-сайтов (а не веб-приложения), поэтому я не могу использовать преобразования web.config.
  • Похоже, что проекты веб-развертывания больше не будут доступны в VS 2012, поэтому я бы предпочел не начинать использовать его сейчас.
  • Публикация профилей может быть хорошим решением, но мы все еще используем VS 2010.

Я убежден, что не первый, кто столкнулся с этой проблемой. Интересно было бы узнать, как люди с этим справились :)


person Pedro    schedule 10.01.2013    source источник
comment
К вашему сведению, вы, похоже, нашли очень вескую причину не использовать проекты веб-сайтов.   -  person John Saunders    schedule 10.01.2013


Ответы (1)


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

Например, на вашей машине разработки поместите свои строки подключения или значения appSettings в C:\Windows\Microsoft.NET\Framework64\v4.0.3031\CONFIG\machine.config (или вашу точную версию) и сделайте то же самое для разных значений в рабочей среде. Файлы конфигурации наследуются, поэтому вам не нужно делать ничего другого в своем коде.

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

person wsanville    schedule 10.01.2013
comment
Я не знал о существовании этих файлов. Его можно использовать для определения некоторых постоянных значений, таких как строки подключения. Спасибо за совет! - person Pedro; 12.01.2013