À quoi servent les fichiers Web.Debug.config et Web.Release.Config?

111

Je viens de passer à Visual Studio 2010 et MVC 2.0 et j'ai remarqué que Web.config a deux fichiers supplémentaires attachés? Ces fichiers sont-ils utilisés pour spécifier des paramètres spécifiques de débogage et de publication, afin de ne pas encombrer le Web.config principal?

Est-il même judicieux de placer une chaîne de connexion dans le fichier racine Web.config si j'en ai une locale et une distante dans le débogage et la version Web.configs respectivement?

Merci!

chobo
la source

Réponses:

97

Il s'agit de la nouvelle fonctionnalité de transformation Web.config de Visual Studio 2010. Plus d'informations ici .


Éditer:

Ces fichiers sont-ils utilisés pour spécifier des paramètres spécifiques de débogage et de publication, afin de ne pas encombrer le web.config principal?

Il n'est pas limité à trois fichiers, vous pourriez (en théorie) avoir autant de fichiers que d'environnements. Le Web.config "de niveau supérieur" fournit un modèle de votre configuration Web. Les fichiers en dessous fournissent des valeurs de remplacement spécifiques à cet environnement (comme si vous avez différentes chaînes de connexion pour local / stage / test / peu importe).

Est-il même judicieux de placer une chaîne de connexion dans le fichier racine web.config si j'en ai une locale et une distante dans le débogage et la version web.configs respectivement.

Cela n'aurait de sens que si cela n'allait pas changer entre les environnements. On dirait que dans votre cas c'est le cas, dans votre cas non, cela n'aurait aucun sens de le laisser dans le Web.config.

R0MANARMY
la source
12
Cette fonctionnalité est à moitié cuite, même 4 ans plus tard! Cela ne fonctionne que lors du déploiement sur des packages Azure / Publishing. Voici un fil de discussion intéressant: forums.asp.net/t/1532038.aspx
Nick
12

Ce sont des fichiers de transformations Web.config. À partir du déploiement Web ASP.NET à l'aide de Visual Studio: Transformations de fichiers Web.config :

Il existe deux façons d'automatiser le processus de modification des paramètres de fichier Web.config: les transformations Web.config et les paramètres Web Deploy. Un fichier de transformation Web.config contient un balisage XML qui spécifie comment modifier le fichier Web.config lorsqu'il est déployé. Vous pouvez spécifier différentes modifications pour des configurations de build spécifiques et pour des profils de publication spécifiques. Les configurations de build par défaut sont Debug et Release, et vous pouvez créer des configurations de build personnalisées. Un profil de publication correspond généralement à un environnement de destination.

eKek0
la source
1

Au cas où quelqu'un serait intéressé, voici quelque chose que j'ai écrit pour avoir une chaîne de connexion dynamique par environnement. Je souhaitais déployer le code dans n'importe quel environnement (Dev, Test, Pre-Prod, Prod ...) sans avoir à me soucier de changer les chaînes de connexion. Je ne pouvais pas vraiment trouver un bon moyen de faire cela avec Asp.Net MVC 4, j'ai donc trouvé ma propre façon de me fier à un fichier de propriétés par environnement.

Il y a peut-être une meilleure solution, je viens d'un fond Wicket / Java et j'ai récemment commencé à développer avec MVC 4, il est donc possible qu'une meilleure solution existe. Mais voici un lien vers ma question et réponse pour une chaîne de connexion dynamique:

Chaîne de connexion dynamique Asp.net MVC 4

eaglei22
la source
-3

C'était quelque chose dont VS avait besoin depuis longtemps. Malheureusement, il semble y avoir un problème avec la mise en œuvre. Par exemple, considérez ce scénario (VS.2010 Ultimate, tous SP):

Web.Config

  • Pas de section connectionStrings
  • Utilisateur / rôle à part entière / etc. Configuration du fournisseur à l'aide de connectionStringName = "test"

Web.Release.Config

  • Aucune configuration d'adhésion (déjà spécifiée dans le principal web.config)
  • section connectionStrings comprenant le CS nommé "test"

Web.Debug.Config

  • Aucune configuration d'adhésion (déjà spécifiée dans le principal web.config)
  • section connectionStrings comprenant le CS nommé "test"

Lors de l'exécution de l'application donne l'erreur suivante:

Le nom de connexion «test» est introuvable dans la configuration des applications ou la chaîne de connexion est vide.

En d'autres termes, comme les éléments de chaîne de connexion se trouvent dans les fichiers du concepteur Release / Debug et sont utilisés par les éléments de configuration dans le fichier principal (Web.config), il ne peut pas le résoudre.

Emile
la source
5
Pour être honnête, si vous avez une chaîne de connexion nommée testà la fois dans vos fichiers de configuration de débogage et de version, elle devrait simplement être dans le web.config principal avec les sections appropriées en modèle. En l'état, vous dupliquez du code, ce que le modèle est censé résoudre pour vous.
R0MANARMY
3
-1: Ce très vieux message était une interprétation totalement erronée de la façon d'utiliser les transformations de configuration Web. 1 Il est pas vraiment une réponse (juste une plainte incorrecte) et 2 il est simple fusion d'éléments comme le laisse entendre ici. Vous devez avoir des xsltcommandes de remplacement explicites . Bravo d'avoir obtenu 5 votes positifs pour quelque chose qui ajoute à la confusion à propos de ces fichiers de transformation :)
Gone Coding