Discussion :

[Kropernic]

Hello,

J'imagine que ce doit être quelque chose de tout simple mais je bute dessus...

Voici le contexte...

J'ai une solution contenant 4 projets. Ces 4 projets sont BLL, DAL, DTO et GUI.

Dans le projet DAL, j'ai ajouté un fichier de type Application Configuration File que j'ai nommé DAL.dll.config.
Dans ses propriétés, j'ai mis Build Action sur Content et Copy to Output Directory sur Copy Always.

Voilà pour le contexte.

Le problème maintenant c'est que, quand je run le projet (ou compile), ce fichier est sensé être copier dans le répertoire bin\debug du projet GUI. Or parfois c'est le cas, parfois ça ne l'est pas.

J'aurais aimé savoir ce qui influe sur cette copie...

Merci d'avance.

[tomlev]

Il n'y a pas de fichier config pour une DLL. Si la DLL a besoin d'infos de configuration, il faut mettre ces infos dans le fichier config de l'exécutable qui l'utilise.

[Kropernic]

Ah bin si. La chaine de connexion à la DB n'a quand même rien à faire dans le fichier config du projet GUI.

En quoi l'accès aux données concerne l'interface utilisateur ?

Il est donc, pour moi, normal d'avoir un fichier config pour la couche d'accès aux données. Je suis tout disposé à avoir l'explication du contraire (je n'ai pas eu de formation .net, ni orienté objet, ni d'architecture...).

D'ailleurs, la plupart du temps, ça fonctionne très bien. Sauf de temps, ce fichier qui ne se copie pas. Et encore, cette non-copie est dans 90% des cas anodines car on ne change pas la chaîne de connexion tous les jours...

C'est d'ailleurs le sujet d'un de mes rares billets de blog.

[tomlev]

Bah c'est pas moi qui ait inventé ce système, c'est comme ça que ça marche et c'est tout

C'est pas une question de GUI ou DAL, c'est une question de point d'entrée du programme. Toute la configuration est définie au niveau de l'exécutable, pour l'exécutable comme pour les DLLs qu'il utilise.

Cette façon de faire est plus flexible (même si ça peut sembler paradoxal à première vue) : si tu as dans ta solution deux exécutables qui veulent utiliser ta DLL, mais pas avec la même configuration, c'est possible, puisque c'est au niveau de l'exécutable que la configuration est définie. Alors que si la conf est définie au niveau de la DLL, tu es coincé...

Pour faire les choses proprement, tu peux te créer une section de configuration personnalisée, comme c'est fait par exemple dans log4net (voir tuto). Ca te permet de regrouper les données de config qui concernent ta DLL.

Après, si tu veux te battre contre le système, fais-toi plaisir, mais à mon avis tu perds ton temps...

[Kropernic]

Sauf que, dans la classe Base de ma couche DAL, si j'essaie d'accéder à My.Settings("laressourcequivabien") en l'ayant mis dans les settings de la couche GUI (de l'exe donc), bin ça ne marche pas...

J'ai raté un tournant quelque part ?

[tomlev]

Ah ok... j'avais pas vu les choses sous cet angle là. Je pensais pas que tu utilisais les settings définis au niveau du projet en fait. Du coup c'est effectivement pas la même chose, et je sais pas du tout comment forcer Visual Studio à copier le fichier...