8

Actuellement, je peux facilement configurer la transformation Web.config en fonction de la configuration de la construction, par ex. utiliser connectionString=server;.. pour Debug et connectionString=./SQLExpress;.. pour Release.Est-il possible de lier la transformation Web.config avec le profil de publication?

Mais est-il possible de faire une transformation Web.config en se basant sur le profil de publication Web? C'est à dire. utiliser connectionString=server1;.. pour le profil Server1 et connectionString=server2;.. pour Server2?

Répondre

0

Je crois que les profils de publication sont indépendants des profils de construction, ce qui est un peu dommage, car vous pourriez facilement déployer accidentellement une configuration de débogage sur vos serveurs de production. Toutefois, si vous utilisez MSDeploy, il existe des moyens de modifier le fichier web.config dans ce répertoire. Voir MSDeploy - Changing Connection string parameter after deploying the package pour plus de détails.

0

Il pourrait y avoir une façon légèrement différente de le faire.

Sur vos serveurs de production, créez une entrée factice, pour customdb, dans le fichier c: \ windows \ system32 \ drivers \ etc \ hosts de chaque machine de production. Chacun pointant vers la base de données que vous voulez que cette machine utilise. Ensuite, il vous suffit de pointer sur la connectionString = customdb; pour tous vos serveurs de production. Seul inconvénient de ceci serait que vous auriez besoin d'accéder au fichier hosts et il vous faudrait utiliser un DB.

Hope this helps

+0

Intéressant. Un autre inconvénient est que vous ne pouvez pas (facilement) contrôler la version du fichier hosts, car il contient des paramètres spécifiques à la machine et ajoute de la complexité au processus de déploiement, nécessitant un accès en écriture aux chemins système normalement évités. – Abel

5

Nous gardons toutes les machines/profil configuration spécifique dans les fichiers de configuration séparés, puis utilisez configSource pour les inclure comme si ...

<connectionStrings configSource="cstrings.config"/> 

Cette Web.config manière est la même et ne nécessite aucune transformation. Nous faisons cela pour les chaînes de connexion, les paramètres SMTP et les paramètres de l'application.

web.config de contrôle de version et nous « machine spécifiques » des fichiers tels que cstrings.config.production, cstrings.config.staging, etc.

Une fois que vous avez cette structure, il est facile de générer des images pour différents profils. Nous avons des scripts de déploiement sur chaque machine qui lisent une variable d'environnement et se déploient de manière appropriée. Par exemple, le script de génération du serveur de transfert copie cstrings.config.staging dans cstrings.config, etc.

+0

Comment exécutez-vous vos scripts de déploiement pour lier le profil actuel et une chaîne de connexion appropriée? – abatishchev

+0

@abatishcev: Notre serveur de construction a des cibles pour le test, la mise en scène et la production. Un checkout propre (export svn réellement) est fait. Créez des scripts "renommez $ {bin} /cstrings.config. $ {Destination} $ {bin} /cstrings.config" puis lancez les tests unitaires, zip et ftp deploy sur la machine de destination. Chaque destination possède des fichiers de configuration cstrings, smtp et appsettings dans le contrôle de version. par exemple, cstrings.config.staging, smtp.config.staging, appsettings.config.staging. FYI: Vous pouvez laisser cstrings.config sur les machines cibles en tant que fichier en lecture seule si vous êtes très soucieux de la sécurité. Ce n'est pas un gros problème dans notre environnement. – Rob