.NET vous permet d'utiliser des fichiers .Settings pour gérer les paramètres d'application. J'aimerais stocker des paramètres de production, de développement et de test séparément de manière à ce que je puisse faire quelque chose comme ceci: Fondamentalement, je veux deux classes de réglages distincts: la classe de paramètres généraux qui stocke le Environnement sélectionné et propriétés spécifiques à l'environnement et 3 instances statiques d'une deuxième classe appelée environnement. L'instance utilisée doit dépendre de l'environnement spécifié dans la classe de paramètres généraux. existe-t-il un moyen de procéder à ce court-circuit de définir manuellement les valeurs de tous ces paramètres dans un constructeur statique ou quelque chose? Si je dois le faire, je préférerais simplement avoir une grande classe de réglages avec des propriétés telles que "DevOutputLocation", "LiveOutputLocation", etc. Je peux avoir plusieurs fichiers .Settings dans mon projet, mais que juste crée des classes séparées qui ne dérivent pas les unes des autres. Donc, je pourrais faire de la développemportation.Settings.SETTAINS, ProductionSettings.Settings et testSettings.Settings Fichiers et donnez-leur les mêmes propriétés, mais j'aurai bien besoin d'une bande de relevés de commutation partout pour déterminer quelle classe à utiliser car elles ne dérivent pas d'une classe commune .
6 Réponses :
juste une idée mais cela peut fonctionner ...
Vous aurez besoin de fichiers de paramètres N + 2 (n des constructions différentes; 2 maîtres) avec contenant les mêmes clés.
Effacer la propriété "Outil personnalisée" pour tous, mais l'un des maîtres (donc un seul le maître génère).
Modifiez le script de pré-construction pour chaque version pour copier le contenu du fichier de paramètres approprié dans le fichier Build-Master.
Modifiez le script post-Build pour copier le contenu du fichier maître secondaire dans le fichier maître d'origine.
Remarque: Si vous pouvez travailler avec votre fournisseur de contrôle source dans les scripts avant et après-construction, vous n'avez pas besoin d'un maître secondaire - vous pouvez simplement vérifier dans la pré-construction et annuler l'annulation dans le post-construction. Cependant, cela peut causer des problèmes dans un environnement d'intégration continue puisqu'un fichier verrouillé nécessiterait la construction d'échec.
Je n'ai aussi jamais fait cela; Bien qu'il y ait des moments où je souhaitais qu'il y ait une façon plus frontale de faire quelque chose comme ça dans VS.
Une pensée est que la commutation entre une série de valeurs statiques ressemble à une manière plutôt longue de faire des choses. Je suggérerais de regarder le modèle singleton. Ce modèle vous donne une seule instance de classe partagée entre toutes les références à la classe, mais lorsqu'il est chargé pour la première fois, vous pouvez effectuer vos bits d'initialisation normaux pour vérifier votre environnement et définir les valeurs en conséquence.
De même, plutôt que d'utiliser des commutateurs pour agir sur différentes classes, ne souhaitez-vous pas concevoir une interface et que chaque classe implémente cette interface?
J'utilise cette approche pour .config fichiers, je suis sûr que cela vous aidera aussi. Il suffit de regarder Blog de Scott Hanselman et . L'idéologie est simple comme l'enfer, mais fonctionne plutôt bien. Tout ce dont vous aurez besoin est de:
Le code d'instanciation de votre classe avec les paramètres examinera toujours les paramètres par défaut (qui seront remplacés après chaque construction avec le besoin nécessaire), cette approche nécessite donc un effort minimal.
Est-ce vraiment le seul moyen? Je suppose que si elle est approuvée par Scott H. Cela ressemble à un hack vraiment désordonné. Vous penseriez que vous pouvez spécifier quel fichier .Settings ou .config fichier à utiliser pour chaque configuration de construction.
Je revenais juste à travers mes questions précédemment posées et je me suis remarquée, je n'ai jamais marqué cela comme répondit, alors vous y allez. Merci encore.
Une autre possibilité est d'utiliser un outil de transformation XML comme Slowcheetah
juste quelques informations supplémentaires sur les fichiers de configuration de l'environnement .NET sans utiliser votre implémentation ci-dessus spécifiquement:
La bibliothèque d'entreprise possède cette fonctionnalité depuis V3.0:
Résumé < / a>
Visual Studio 2010 aura également cette fonctionnalité. C'est appelé transformation de configuration
Il y a un peu de frais généraux impliqués dans la vérification de la détermination de l'environnement dans lequel vous rencontrez. Si vous parlez d'un environnement Web, cela pourrait signifier une performance significative. Je vous recommanderais de créer trois fichiers de configuration distincts et de configurer un système d'intégration et de déploiement continu qui gère la nommée et déploie le fichier de paramètres approprié en fonction de l'environnement. Dans votre cas, vous auriez trois fichiers, production.config, développement.config et test.config. Le serveur d'intégration créerait ensuite une copie de ce fichier pour web.config ou app.config en fonction de l'environnement.
En ce qui concerne tout entretien supplémentaire impliqué dans la maintenance de trois fichiers distincts chaque fois qu'un changement de configuration est effectué, nous gardons les fichiers formatés automatiquement et utilisez quelque chose comme Winmerge pour voir facilement les différences et les conserver correctement. Ces types de fichiers ne nécessitent généralement pas de nombreuses modifications et quand ils sont généralement des ajouts mineurs.
Je fais actuellement quelque chose de similaire à la solution mentionnée par PDavis. Mais pour simplifier de multiples fichiers de configuration, j'utilise un modèle T4 pour créer les fichiers de configuration spécifiques à l'environnement. De cette façon, il y a un fichier web.tt qui gère la génération du fichier web.config par défaut. Chaque environnement a son propre fichier de modèle (qa.tt, production.tt, etc.) qui hérite de web.tt et contient des substitutions spécifiques à l'environnement. Toute modification de la configuration Web - Les nouveaux paramètres d'application, les paramètres de configuration, etc. sont automatiquement propagés à tous les fichiers de configuration spécifiques de la région en régénérant les modèles et vous n'avez pas à vous soucier de garder les fichiers en synchronisation à l'aide d'un outil DIFF.
Vous pouvez le faire en utilisant un utilisateur différent pour chaque environnement, mais je pense en quelque sorte que cela entraîne davantage de problèmes que ce qu'il résoue.