Utilisation de différents Web.config dans les environnements de développement et de production
J'ai besoin d'utiliser une chaîne de connexion à la base de données et une adresse de serveur SMTP différentes dans mon application ASP.NET, selon qu'elle est exécutée dans un environnement de développement ou de production.
L'application lit les paramètres du fichier Web.config via la propriété WebConfigurationManager.AppSettings .
J'utilise la commande Construire/Publier pour déployer l'application sur un serveur de production via FTP, puis remplace manuellement le fichier Web.config distant par le correct.
Est-il possible en quelque sorte de simplifier le processus de déploiement? Merci!
Dans Visual Studio 2010 et versions ultérieures, vous avez maintenant la possibilité d'appliquer une transformation à votre fichier web.config en fonction de la configuration de la construction.
Lors de la création d'un fichier web.config, vous pouvez développer le fichier dans l'explorateur de la solution. Deux fichiers sont alors visibles:
- Web.Debug.Config
- Web.Release.Config
Ils contiennent du code de transformation qui peut être utilisé pour
- Changer la chaîne de connexion
- Supprimer la trace et les paramètres de débogage
- Enregistrer les pages d'erreur
Reportez-vous à Syntaxe de transformation Web.config pour le déploiement de projets d'application Web sur MSDN pour plus d'informations.
Il est également possible, bien que officiellement non supporté, d’appliquer le même type de transformation à une application non Web app.config fichier. Voir blog de Phil Bolduc pour savoir comment modifier votre fichier de projet afin d’ajouter une nouvelle tâche à msbuild.
C'est une longue attente demande sur le Visual Studio Uservoice .
Un extension pour Visual Studio 201 et supérieur, " SlowCheetah ", est disponible pour prendre en charge la création de la transformation pour tout fichier de configuration. À partir de Visual Studio 2017.3, SlowCheetah a été intégré à l'EDI et la base de code est gérée par Microsoft. Cette nouvelle version prend également en charge la transformation JSON.
La balise <appSettings> Dans web.config prend en charge un attribut de fichier qui chargera une configuration externe avec son propre ensemble de clés/valeurs. Ceux-ci remplaceront tous les paramètres que vous avez dans votre web.config ou y seront ajoutés.
Nous en tirons parti en modifiant notre web.config au moment de l’installation avec un attribut de fichier correspondant à l’environnement d’installation du site. Nous faisons cela avec un interrupteur sur notre installateur.
par exemple;
<appSettings file=".\EnvironmentSpecificConfigurations\dev.config">
<appSettings file=".\EnvironmentSpecificConfigurations\qa.config">
<appSettings file=".\EnvironmentSpecificConfigurations\production.config">
Remarque:
- Les modifications apportées au fichier .config spécifié par l'attribut ne déclenchent pas le redémarrage du processus de travail asp.net
Avez-vous consulté des projets de déploiement Web?
Il existe également une version pour VS2005, si vous n’êtes pas en 2008.
J'aimerais aussi savoir. Cela aide à isoler le problème pour moi
<connectionStrings configSource = "connectionStrings.config" />
Je garde ensuite un fichier connectionStrings.config ainsi qu'un "{hôte} connectionStrings.config". C'est toujours un problème, mais si vous faites cela pour des sections qui diffèrent dans les deux environnements, vous pouvez déployer et mettre à jour le même web.config.
(Et je n'utilise pas VS, d'ailleurs.)
J'utilise un script de génération NAnt pour déployer dans mes différents environnements. Je le fais modifier mes fichiers de configuration via XPath en fonction de l'endroit où ils sont déployés, puis les met automatiquement dans cet environnement en utilisant Beyond Compare .
Prend une minute ou deux à l’installation, mais vous n’avez besoin que de le faire une fois. Ensuite, les dossiers de lot prennent le relais pendant que je vais chercher une autre tasse de café. :)
Voici un article que j'ai trouvé dessus.
Sur un projet où nous avions 4 environnements (développement, test, stockage intermédiaire et production), nous avons développé un système dans lequel l'application sélectionnait la configuration appropriée en fonction du nom de la machine sur laquelle elle avait été déployée.
Cela a fonctionné pour nous parce que:
- les administrateurs peuvent déployer des applications sans impliquer les développeurs (une exigence) et sans avoir à manipuler les fichiers de configuration (ce qu'ils ont détesté);
- les noms de machines adhéraient à une convention. Nous avons apparié les noms à l'aide d'une expression régulière et les avons déployés sur plusieurs machines d'un environnement. et
- nous avons utilisé la sécurité intégrée pour les chaînes de connexion. Cela signifie que nous pourrions conserver les noms de compte dans nos fichiers de configuration au moment de la conception sans révéler aucun mot de passe.
Cela a bien fonctionné pour nous dans ce cas, mais ne fonctionnerait probablement pas partout.
L'éditeur de configuration d'Enterprise Library peut vous aider. Il vous permet de créer un fichier de configuration de base, puis des deltas pour chaque environnement. Vous pouvez ensuite fusionner la configuration de base et le delta pour créer un fichier web.config spécifique à l'environnement. Regardez l'information ici qui vous guide mieux que moi.
Vous pouvez également en faire une étape post-construction. Configurez une nouvelle configuration "Deploy" en plus de Debug et Release, puis copiez l'étape de post-génération sur le bon web.config.
Nous utilisons des versions automatisées pour tous nos projets. Avec celles-ci, le script de génération met à jour le fichier web.config afin qu'il pointe vers l'emplacement correct. Mais cela ne vous aidera pas si vous faites tout de VS.
C’est l’un des gros avantages de l’utilisation de machine.config. Lors de mon dernier emploi, nous avions des environnements de développement, de test et de production. Nous pourrions utiliser le fichier machine.config pour des choses telles que les chaînes de connexion (vers la machine SQL appropriée, dev/test/prod).
Cela peut ne pas être une solution pour vous si vous n'avez pas accès à la machine de production réelle (comme si vous utilisiez une société d'hébergement sur un hôte partagé).