J'ai besoin d'avoir une dll .NET 3.5 avoir son propre fichier de configuration. Cette DLL pourrait être appelée à partir de nombreuses applications différentes afin que les informations (telles que les chaînes de connexion) stockées dans le fichier de configuration soient conservées dans un fichier de configuration que la DLL peut faire référence. Ce que je veux, c'est lorsque la DLL est utilisée, j'ai besoin de "commuter" le fichier de configuration utilisé pour référencer les informations pour être le fichier de configuration DLLS. Ensuite, lorsque la DLL est terminée à l'aide des informations de configuration, le commutateur est renvoyé à la valeur par défaut. La DLL est écrite en utilisant .NET 3.5. Je cherchais comment faire cela et ce que je continue à trouver, c'est comment fusionner des informations avec un fichier App.config d'EXE. Dans mon cas, je ne sais pas comment cette DLL sera utilisée pour modifier les fichiers app.config d'EXE. Cette solution doit être autonome seule. Cependant, mes classes de base utilisées pour créer la DLL (contenant des objets métier) s'attendent à consulter la chaîne de connexion et d'autres informations dans un fichier de configuration, c'est pourquoi j'ai besoin de "commuter" sur mon fichier de configuration DLL au moment où il est accessible et ensuite le basculer pour que je ne gâche pas l'application EXE appelée DLL.
5 Réponses :
La réponse la plus facile à cela serait de mettre les valeurs dans la machine.config. Ainsi, toutes les applications utilisant la DLL pourront accéder aux informations via les classes de configuration de l'application .NET. De cette manière également, si vous avez absolument besoin de remplacer une valeur d'une certaine applicatine, vous pouvez le remplacer dans le fichier app.config du principal.
Vous ne pouvez pas utiliser le système de configuration intégré .NET pour le faire. Il est conçu (comme il devrait être) de configurer les processus d'application et non des DLL indevidales. La bonne façon d'y aller consiste à ajouter les paramètres de configuration de la DLL dans le système app.config pour chaque application exécutable qui "utilise" (a une référence à) que DLL. (ou dans la machine.config)
Si vous ne voulez pas le faire de cette façon, vous devrez écrire votre propre code pour ouvrir, lire et écrire FRM un fichier XML personnalisé (ou tout autre format que vous choisissez d'utiliser) à l'extyract ces paramètres .
Ah, vous pouvez - c'est un peu de travail et non aussi grand et sans soudure que l'histoire app.config - mais cela fonctionne. Et la plupart du temps, je suis d'accord - l'application hôte devrait fournir config. Je vois des cas si une configuration séparée spécifique à la bibliothèque peut aussi faire beaucoup de sens.
En règle générale lorsque vous avez des paramètres au niveau de l'application, vous devez générer ces paramètres au niveau de l'application, puis les percoler dans vos bibliothèques. Il ajoute quelques autres lignes de code à votre initialisation pour injecter des dépendances, mais vous essayez essentiellement de le faire quand même.
Vous allez passer à bien plus de problèmes que sa valeur si vous essayez d'inclure un fichier de configuration pour simplement la DLL côte à côte avec chaque déploiement de votre bibliothèque, et cela n'a tout simplement pas beaucoup de sens sémantiquement.
prendre System.Data, par exemple ... Lorsque vous créez une connexion, vous spécifiez la chaîne de connexion, ne crée pas de fichier de configuration distincte pour une seule chaîne de connexion à déployer côte à côte avec la bibliothèque System.Data. [Et cela entraînerait des tonnes de problèmes car elle réside probablement dans le GAC sur votre système de toute façon]
Le système de configuration .NET 2.0 et UP vous donne des capacités - vous pouvez par exemple. Chargez un fichier de configuration spécifique à la demande. C'est un peu plus de travail - mais cela fonctionne.
Vous devriez faire quelque chose comme ceci: Vous devez également vous assurer que la configuration de la classe La DLL de la bibliothèque est en construction et copiée dans un endroit où vous pouvez en obtenir. Le pire cas, vous devez spécifier un fichier de configuration spécifique et vous assurer qu'il est copié dans le répertoire de sortie en définissant la propriété "Copier sur le répertoire de sortie" dans la fenêtre Visual Studio Propriétés. Vous devez également vérifier JON La série en trois parties de Rista sur la configuration .NET 2.0 sur CodeProject. fortement recommandé, bien écrit et extrêmement utile! marc
Cela semble prometteur d'utiliser cette approche. J'ai une question cependant, je n'ai pas à "annuler" cela? Est-ce que ma configuration DLL sera la configuration "Par défaut" pour la recherche?
Non - vous devez demander explicitement un objet "Configuration" à partir de la configurationManager, et uniquement si vous travaillez sur cet objet distinct obtiendrez-vous ces paramètres distincts.
Je sais que ce post est un peu vieux, mais je voulais jeter mes 2 centimes. Tandis que dans les cas de mai, je conviendrais que l'application doit fournir les paramètres, et non la DLL. J'ai trouvé une situation dans tandis que les configurations spécifiques à la DLL semblent plus souhaibles.
Nous utilisons l'application de planification / tâche requérante quartz.net. Nous avons développé une interface pour créer et surveiller des travaux sur le serveur de quartz. L'une des grandes choses sur QUARTZ.NET est que vous créez vos programmes "travail" et les compiler dans des DLL, puis déposez-les dans le dossier serveur Quartz.NET et sur la réflexion, etc., le quartz est capable de commencer à utiliser la nouvelle DLL. Sans Tweaks supplémentaires sur Quartz Server ... S'il n'y a aucune information qui doit être conservée dans des fichiers de configuration.
avec serveur de quartz Si vous avez des informations de configuration spécifiques qui doivent être conservées dans un fichier de configuration, vous devez le mettre dans le fichier de configuration Quartz.net. Nous avons créé plusieurs applications "travail", chacune avec leurs propres bits d'informations de configuration, alors maintenant notre fichier de configuration quartz.net est jonchée de tous ces paramètres non liés. Avoir un fichier de configuration spécifique à la DLL réduirait considérablement l'encombrement du serveur Quartz.net. La seule autre option que je vois consiste à ajouter tous ces paramètres individuels dans une table DB Paramètres, mais pour la consolidation et la maintenance du code, à nos fins, des fichiers de configuration individuels sont préférables.
Je viens de lancer ça là-bas pour penser.