Différents fichiers de configuration pour le développement et la production dans l'application ASP.NET

Question

Sur un projet sur lequel nous travaillons, nous avons une application Web avec trois fichiers de configuration; Web.Config Web.Config.TestServer Web.Config.LiveServer

Lorsque nous libérons au serveur de test, Web.Config est renommé Web.Config.Development et Web.Config.TestServer est renommé Web. Config, rendant cette configuration active pour l'application.

Il est assez onéreux de garder trois fichiers de configuration très similaires à jour, et ce système est utilisé dans un certain nombre d'applications qui font partie de ce projet; pas seulement le site Web.

Les différences de configuration sont le plus souvent des répertoires ou des chemins locaux, des adresses URL, des adresses IP, des numéros de port et des adresses électroniques.

Je suis à la recherche d'un meilleur moyen.

Answer 1

Alors que votre approche semble fastidieuse, je trouve que c'est la meilleure approche.

J'avais l'habitude de garder toutes mes configurations dans un seul fichier web.config, et j'avais simplement la section "production" commentée. Peu de temps après cela, j'ai dû faire un test "hybride" où mes données de recherche provenaient du serveur de production, mais les nouvelles données étaient insérées dans la base de données de test. À ce moment-là, j'ai dû commencer à découper à la pièce les parties du bloc de configuration à commenter/décomposer, et c'est devenu un cauchemar.

De même, nos administrateurs de serveurs font la migration réelle de test à production, et la plupart d'entre eux ne maîtrisent pas suffisamment le .NET pour savoir comment gérer les fichiers web.config. Il est beaucoup plus facile pour eux de simplement voir un fichier .test ou .prod et migrer le bon. Vous pouvez utiliser quelque chose comme une base de données pour stocker toutes vos configurations, mais vous vous retrouvez alors dans une autre couche d'abstraction et vous devez gérer cela en plus des choses. Une fois que vous obtenez le talent ou le modèle de configuration de vos deux (ou trois) fichiers de configuration, il devient beaucoup plus facile de les gérer et vous pouvez faire modifier votre configuration de serveur de test pour des tests uniques sans beaucoup tracas.

Answer 2

Si vous avez un serveur db dans le mix, vous pouvez créer une table qui a la config, le nom de la propriété, et la valeur de la propriété, alors tout ce que vous avez à faire est de changer une valeur dans le web.config , le nom de la config (dev, test, prod).

Si vous avez des dbs différents pour chaque configuration, alors la seule chose qui est différente est la chaîne de connexion.

Answer 3

Utilisez Config Transformation et il existe un blog à ce sujet.

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

Fondamentalement, vous créez des cibles nommées web. {Construire configuration} .config. Dans chaque fichier cible, vous écrivez votre transformation où vous pouvez ajouter, supprimer et modifier des nœuds et des attributs. Exemple pourrait être

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> 

Vous pouvez ensuite exécuter la transformation en appelant MSBuild {project file} /t:TransformWebConfig /p:Configuration=Staging