Discussion :

[loulouklm]

Hello,

J'aimerai échanger sur le sujet des paramètres de PROD et de DEV. Dans tous les développements, on utilise des paramètres qui diffèrent selon l'environnement.

Exemples typiques : l'url du serveur SMTP, la chaine de connexion à la DB.

Comment et où stockez-vous cette information ?

Web.config, oui mais, cela ne permet plus d'utiliser la publication intégrée à VS.

Merci pour vos astuces !

[Nicolas Esprit]

Bonjour,

C'est là que la transformation de fichier Web.config, apparue avec Visual Studio 2010, intervient.

Pour plus d'info, voir mon article sur le déploiement web avec VS 2010.

Après, il y a bien sûr d'autres solutions : des tools maison, des tools payant, etc.

En espérant t'avoir aidé.

[Philippe Vialatte]

Salut,

dans mon environnement actuel, le processus de builds est externe à VS (nant), et change les paramètres en fonction des options de build :p

Dans une autre boite, ils mettent les chaines de connection, serveur smtp & co dans le machine.config

[Nicolas Esprit]

Dans une autre boite, ils mettent les chaines de connection, serveur smtp & co dans le machine.config

Bizarre cette idée d'utiliser le machine.config je trouve. D'une part parce qu'il y a des paramètres propres à une application et pas à tout un serveur Web. D'autre part si un changement intervient dans le machine.config, ok pas besoin de redémarrer IIS, mais la prochaine requête va causer le redémarrage de toutes les applications Web de la machine.
Dans ce cas là je trouve qu'il vaut mieux utiliser le web.config, seule l'application concernée sera redémarrée.

Bref, un changement mineur sur une application avec modif du machine.config entraîne le redémarrage de toutes les applis. Si jamais certaines applis utilisent beaucoup le cache... arf.

[Philippe Vialatte]

Bizarre cette idée d'utiliser le machine.config je trouve. D'une part parce qu'il y a des paramètres propres à une application et pas à tout un serveur Web. D'autre part si un changement intervient dans le machine.config, ok pas besoin de redémarrer IIS, mais la prochaine requête va causer le redémarrage de toutes les applications Web de la machine.
Dans ce cas là je trouve qu'il vaut mieux utiliser le web.config, seule l'application concernée sera redémarrée.

Je suis bien d'accord, c'est pas la meilleur idée du siècle...sauf que dans leur cas, ca se tenait (3 ou 4 bases de données partagées entre une cinquantaine d'appli), et qu'il faut bien sur ne pas aller jusqu'au bout de la logique, avec *tous* les paramètres dans le machine.config

Bref, un changement mineur sur une application avec modif du machine.config entraîne le redémarrage de toutes les applis. Si jamais certaines applis utilisent beaucoup le cache... arf.

Pour mitiger, vu qu'il y tenaient et que l'archi s'y prétait bien, j'avais bataillé pour passer la session dans un serveur d'état et le cache dans un système de cache décentralisé.

C'etait de plus un ensemble d'applis "entreprise", avec un ensemble d'étapes et de papiers à signer et tamponner dans tous les sens avant mise en prod

[loulouklm]

Merci pour vos réponses. Je vais pouvoir déployer plus rapidement.
Très bon article Nicolas.

Bonne journée