Discussion :

[slim]

Bonjour,

J'ai créé une bibliothèque de classes ayant un fichier de config à la racine du projet (App.Config). J'ai ajouté quelques sections personnalisées utilisées par l'application. Après génération de la dll et son importation dans une application console pour la tester, il faut que j'ajoute à l'application console un fichier de config comportant les mêmes éléments que le fichier de config de la bibliothèque de classes. Est-ce que vous trouvez cela normal ?

J'ai vu ce thread, mais là, le fichier config est déplacé vers l'application hote de la DLL. Ce n'est pas ce que je veux faire.... je voudrais bien que ce soit "le tout" qui est importé.

Comment puis-je faire pour intégrer le App.config à la dll sans devoir l'importer dans les projets utilisant celle-ci ?

Merci.

[rabddoul]

Salut ,

Je ne suis pas expert des appConfig mais j'aurais tendance à dire que ca n'est pas faisaible. Un appconfig est , pour moi, forcément liée à une application et pas à une librairie de classe.

[lysiandad]

forcément liée à une application et pas à une librairie de classe.

Oui et non, c'est un peu plus compliqué que ça.

En fait la configuration d'un code executable .NET se fait par AppDomain. Donc, oui, l'App.config que VS propose par défaut pour un projet executable ".exe" est bien celui de l'application, pour l'AppDomain par defaut de celle ci.

Et "non", car on peut, moyennant un peu de code ad hoc, charger un assembly séparé (la DLL en question) utilisé par l'application dans un AppDomain "secondaire" qui aura sa propre configuration ; via :

http://msdn.microsoft.com/fr-fr/libr...y0(VS.80).aspx

Mais le problème, c'est que cela devient intrusif sur le code applicatif car executer du code .NET a travers des assemblies differents au sens du meme AppDomain c'est totalement transparent, mais cela n'est plus du tout le cas quand il y a plus d'un AppDomain (celui par defaut de l'application) : il faut alors avoir recours a des techniques de communication inter-AppDomains, puisque precisement ceux ci sont conçus pour isoler / proteger des "domaines de code" d'effets de bord des uns des autres au sein de l'application...

Bref.

Il est probablement plus simple (si le besoin d'isolation via AppDomains ne se fait pas sentir) de s'en tenir au seul AppDomain par defaut de l'appli, avec le seul App.config du projet .exe, et de "dispatcher" la semantique de configuration des differents assemblies dans des sections séparées (plutot que tout mettre "en vrac" en <appSettings> p.ex) ; voir :

http://msdn.microsoft.com/en-us/libr...onsection.aspx

'HTH

[slim]

Salut!

j'aurais tendance à dire que ca n'est pas faisaible.

hé si !
je viens de le faire

Alors, il faut faire comme ceci pour ouvrir le fichier de config de la librairie de classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

private Configuration config = ConfigurationManager.OpenExeConfiguration("MaLibrairieDeClasse.dll");

Puis, ce code permet de récupérer les valeurs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
foreach (KeyValueConfigurationElement kvce in config.AppSettings.Settings)
            {
                if (kvce.Key.StartsWith("nomExemple"))
                {
                    maVariable = config.AppSettings.Settings[kvce.Key].Value;
                }
            }

Après, on peut importer la dll mais il faut copier le fichier config de la dll dans le meme répertoire que la dll...

Voila

[lysiandad]

Ah, bien vu J'avais oublié ce truchement...