2009-11-26 7 views
4

J'ai récemment reçu un tas de programmes à maintenir et j'essaie de trouver de l'aide pour adopter quelques bonnes pratiques. Ils sont essentiellement trois logiciels indépendants qui utilisent une DLL commune pour gérer une série de paramètres que les applications partagent tous. La DLL fonctionne de cette façon: elle échange le fichier de paramètres utilisateur (fichier XML enfoui dans le dossier des configurations de l'utilisateur dans Windows), avec un fichier de correctif, spécifié par un chemin codé en dur (egad!). La logique derrière les paramètres utilisateur et non les paramètres de l'application est que la DLL peut être trouvée dans plusieurs emplacements (un pour chaque application qui va l'utiliser), et donc le fichier de paramètres utilisateur est commun (si tout les copies de la DLL sont la même compilation), tandis qu'en utilisant les paramètres d'application, il y aurait autant de fichiers app.config que de copies de la DLL. J'essaie de concevoir une meilleure façon de centraliser ces configurations et mettre fin à l'échange de fichiers insensé. Une approche (en fait, probablement la meilleure approche) serait de reconcevoir les 3 applications afin qu'elles utilisent toutes une DLL centrale avec son propre "app.config". Y a-t-il d'autres lieux plus recommandés?Paramètres centralisés en C# pour plusieurs programmes

+0

Lorsque vous exécutez une application, seul le fichier app.config du fichier .exe est chargé. Les paramètres ne sont pas chargés à partir d'un fichier .config distinct pour chaque DLL que vous utilisez. – ScottS

+0

Avez-vous vérifié que si vous définissez les paramètres de la DLL à Machine que vous avez plusieurs par DLL? Je suis sur mon macbook en ce moment et je ne peux pas confirmer. – user7116

+0

@ScottS: Les paramètres appartiennent à la DLL dans ce cas, pas les applications. – MPelletier

Répondre

7

Avez-vous envisagé d'utiliser le registre Windows? Nous le détestons tous, mais c'est peut-être la meilleure option dans ce cas car elle est centralisée et vous pouvez partager les paramètres facilement entre les applications. Si vous n'aimez pas le Registre (et je ne vous blâme pas pour cela), vous pouvez créer un fichier XML ou un autre fichier de configuration dans un répertoire du dossier spécial Application Data. C'est ainsi que cela se fait ces jours-ci pour autant que je sache.

string appData = Environment.GetFolderPath(
    Environment.SpecialFolder.LocalApplicationData)); 
string folder = "MyApplicationName"; 
string fileName = "settings.xml"; 
string path = Path.Combine(Path.Combine(appData, folder), fileName); 
+0

Avoir, préfèrent ne pas cependant. Je pensais que l'idée générale était de s'éloigner du registre. Ce n'est pas une mauvaise idée, mais j'aimerais voir d'autres options. – MPelletier

+1

Haine de donner une autre jambe au registre, mais c'est probablement la meilleure réponse. Mine trompée. ;) – jrista

+2

@MPelletier: En ce qui concerne la configuration centralisée, je pense que le registre est la meilleure option. Vous pouvez utiliser une base de données, écrire votre propre cadre de configuration et stocker votre configuration de manière personnalisée, etc. etc. Chose est, le registre est omniprésent dans Windows ... c'est juste là, et facilement accessible. Difficile de se tromper avec ça. Je recommande d'écrire un emballage autour de l'accès au registre, au cas où vous trouveriez une meilleure solution dans le futur. Cela aurait moins d'impact sur votre application de cette façon. – jrista

2

Pour ce problème précis, si elle est une DLL .Net, vous pouvez utiliser le GAC, ce centraliserait votre DLL. Tous les logiciels sauraient où ils pourraient accéder à cette DLL. Et de cette façon, vous pourriez avoir moins de refactoring à faire.

Ceci est seulement un correctif pour ce problème seulement. Je ne recommanderais pas cela, pour un nouveau développement.

GAC in Wikipedia

+0

Les différentes applications disposeraient toujours de répertoires de travail et de fichiers de configuration séparés, de sorte que le problème de localisation des paramètres persistera. –

+1

Comme je le comprends, la DLL est le point central de la configuration. Puisque tous résident dans la DLL s'il devait être mis dans le GAC, tout serait centralisé –

2

Vous pouvez utiliser les paramètres dans un fichier commun - très probablement stocké sous AppData dans les utilisateurs des paramètres du dossier

L'avantage ici est que vous ne devez pas modifier un code que ce soit.

L'application stockerait ses paramètres dans son fichier de configuration normale et consultez le fichier commun pour les paramètres dll:

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
    <appSettings file="commondll.config"> 
    <add key="KeyToOverride" value="Original" /> 
    <add key="KeyToNotOverride" value="Standard" /> 
    </appSettings> 
</configuration> 

puis dans le fichier commun commondll.config:

<appSettings> 
    <add key="KeyToOverride" value="Overridden" /> 
    <add key="KeyToBeAdded" value="EntirelyNew" /> 
</appSettings> 
Questions connexes