Различные конфигурационные файлы для разработки и производства в приложении ASP.NET - PullRequest
Новая
       11

Различные конфигурационные файлы для разработки и производства в приложении ASP.NET

3 голосов
/ 13 февраля 2009

В проекте, над которым я работаю, у нас есть веб-приложение с тремя файлами конфигурации; Web.Config Web.Config.TestServer Web.Config.LiveServer

Когда мы выпускаем на тестовый сервер, Web.Config переименовывается в Web.Config.Development, а Web.Config.TestServer переименовывается в Web.Config, делая эту конфигурацию активной для приложения.

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

Различия в конфигурации чаще всего связаны с локальными каталогами или путями, URL-адресами, IP-адресами, номерами портов и адресами электронной почты.

Я ищу лучший способ.

Ответы [ 3 ]

3 голосов
/ 13 февраля 2009

Хотя ваш подход кажется утомительным, я считаю, что он лучший.

Я имел обыкновение хранить все свои конфигурации в одном файле web.config, и просто закомментировал раздел «production».

Вскоре после этого мне пришлось провести «гибридный» тест, в котором мои поисковые данные приходили с рабочего сервера, но новые данные вставлялись в тестовую базу данных. В этот момент мне пришлось начать по частям, какие части конфигурационного блока комментировать / раскомментировать, и это стало кошмаром.

Аналогичным образом, наши администраторы серверов осуществляют фактический переход от тестирования к производству, и большинство из них недостаточно свободно владеют .NET, чтобы знать, как управлять файлами web.config. Им гораздо проще просто просмотреть файл .test или .prod и перенести нужный файл вверх.

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

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

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

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

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

1 голос
/ 06 января 2011

Используйте Config Transformation, и здесь есть блог об этом.

http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx

В основном вы создаете цели с именем web. {Build configuration} .config. В каждом целевом файле вы пишете свое преобразование, где вы можете добавлять, удалять и изменять узлы и атрибуты. Примером может быть 

web.staging.configss

<?xml version="1.0"?> 
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> 
     <connectionStrings> 
        <add name="personalDB" 
          connectionString="Server=StagingBox; Database=personal; User Id=admin; password=StagingPersonalPassword" 
          providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)" /> 
        <add name="professionalDB" 
         connectionString="Server=StagingBox; Database=professional; User Id=professional; password=StagingProfessionalPassword" 
         providerName="System.Data.SqlClient" xdt:Transform="Replace" xdt:Locator="Match(name)"/> 
       </connectionStrings> 
</configuration>

Затем вы выполняете преобразование, вызывая MSBuild {project file} /t:TransformWebConfig /p:Configuration=Staging

...