Oui, vous pouvez utiliser le configSource
du bloc de configuration. Tous les blocs de configuration possèdent cet attribut - bien qu'il ne soit pas documenté.
Véase cet article tout en bas, à l'annexe B. J'ai également collé la section pertinente ci-dessous :
Annexe B : inclusion de fichiers de configuration externes
Malgré toutes les qualités des fonctions de configuration de .NET 2.0, il y a un inconvénient. Lorsqu'on travaille sur un seul projet dans plusieurs environnements, la gestion de la configuration peut devenir un cauchemar. Dans le cadre de mon travail actuel, la gestion de plusieurs versions d'un fichier de configuration pour plusieurs environnements - c'est-à-dire le développement, les tests, la mise en place et la production - implique des comparaisons manuelles des éléments suivants .config
à chaque fois que des changements sont déployés dans un environnement ou un autre, avec un processus de fusion manuel. J'ai passé des mois à essayer de trouver une meilleure solution et j'ai fini par en trouver une. C'est alors qu'est apparue l'une de ces fonctions "non documentées" - ou, dans ce cas, mal documentées - dont Microsoft est si célèbre : configSource
. Je suis tombé sur ce petit bijou en fouillant dans le code source de la configuration de .NET 2.0 avec Reflector, un merveilleux petit outil.
Chaque section de configuration, lorsqu'elle est analysée et chargée par les classes de configuration .NET, se voit attribuer un nom d'utilisateur et un mot de passe. SectionInformation
objet. Le site SectionInformation
contient des méta-informations sur une section de configuration et permet de gérer la manière dont les sections se substituent les unes aux autres lorsqu'elles sont définies dans un fichier de configuration enfant (ASP.NET). Pour l'instant, nous allons ignorer la majorité de ce que SectionInformation a à offrir, à l'exception de l'objet ConfigSource
propriété. En ajoutant un configSource
à l'élément Root de toute ConfigurationSection
vous pouvez spécifier une autre source externe à partir de laquelle les paramètres de configuration seront chargés.
<!-- SomeProgram.exe.config -->
<configuration>
<connectionStrings configSource="externalConfig/connectionStrings.config"/>
</configuration>
<!-- externalConfig/connectionStrings.config -->
<connectionStrings>
<add name="conn" connectionString="blahblah" />
</connectionStrings>
Dans le fichier de configuration ci-dessus, l'élément <connectionStrings>
provient d'un fichier appelé externalConfig/connectionStrings.config
. Toutes les chaînes de connexion de l'application seront chargées à partir du fichier spécifié. Maintenant que les chaînes de connexion sont chargées à partir d'une ressource externe, il est relativement simple de créer un fichier de type connectionStrings.config
dans chaque environnement au même emplacement relatif. Par conséquent, le externalConfig/
partie de la connectionStrings.config
chemin. La beauté de la chose est que nous pouvons définir les chaînes de connexion correctement pour chaque environnement une seule fois. Nous n'avons pas à nous soucier de remplacer accidentellement ces paramètres lors d'un déploiement où un fichier de configuration a été fusionné de manière incorrecte ou n'a pas été fusionné du tout. Cela peut être un avantage considérable lors du déploiement des modifications d'une application dans un environnement de production, où il est essentiel que les chaînes de connexion à la base de données soient correctes. L'inconvénient de l'utilisation de la fonction configSource
est qu'il exige que tous les paramètres de configuration soient placés dans le fichier externe. Aucun héritage ou remplacement n'est possible, ce qui le rend inutile dans certains cas. Tous les fichiers de configuration externes utilisés avec l'attribut configSource
doit également se trouver dans un chemin d'accès enfant relatif au chemin d'accès principal. .config
fichier. Je pense que cela est dû à des problèmes de sécurité liés au stockage du fichier dans un chemin parent relatif dans un environnement Web.
Il convient également de noter que le <appSettings>
a une meilleure alternative à l'utilisation de configSource
appelé fichier. Si vous utilisez l'attribut file plutôt que configSource avec l'attribut <appSettings>
vous pouvez définir des paramètres à la fois dans la section Root .config
et dans le fichier référencé. Paramètres de la racine .config
peut également être remplacée dans le fichier référencé, simplement en ajoutant quelque chose avec la même clé. Malheureusement, l'attribut file n'est disponible que sur l'objet <appSettings>
et n'est pas intégré dans le cadre de la configuration. Il est possible d'implémenter un attribut similaire dans vos propres sections de configuration. Cette question sera abordée dans un prochain épisode des sujets de configuration avancée, après plusieurs épisodes de prérequis ;).