Discussion :

[EmacLi]

Bonjour à tous,

Pour faire court, j'ai une dll (test.dll) qui référence un service wcf.

J'ai un projet qui référence cette dll mais si je ne copie pas le test.dll.config de ma dll dans mon projet (renommé en app.config), ça ne fonctionne pas :

Impossible de trouver un élément de point de terminaison par défaut qui fait référence au contrat '...' dans la section de configuration du client ServiceModel. Ceci peut être dû au fait que le fichier de configuration de votre application est introuvable ou que l'élément de point de terminaison correspondant à ce contrat est introuvable dans l'élément client.

Ce que j'en conclu c'est que chaque projet suceptible d'utiliser un service wcf doit le référence directement et ne peux pas passer par un assembly tier.

Pas très malin wcf !
Y a t'il une manière plus propre que de copier le fichier à la main ?

Merci d'avance à tous,
(frk 4.0, vs2010)

[Nathanael Marchand]

Qu'y a t il dans le fichier de configuration de ton application?

[tomlev]

C'est normal : seuls les exécutables ont un fichier de configuration. Visual Studio le crée quand même pour une DLL, mais il n'est jamais utilisé, c'est toujours le fichier de configuration de l'exe qui est utilisé. Et ce n'est pas spécifique à WCF, c'est comme ça dans tout .NET. Ca n'aurait pas de sens de définir la configuration d'une DLL, vu que la DLL pourrait être utilisée par d'autres exécutables qui auraient besoin d'une configuration différente. Cette solution est beaucoup plus souple.

Le fichier de conf que tu as pour ta DLL doit être fusionné avec celui de l'exécutable qui utilise la DLL.

[EmacLi]

Qu'y a t il dans le fichier de configuration de ton application?

J'ai uniquement la configuration de référence de mon service wcf (binding, client)

C'est normal : seuls les exécutables ont un fichier de configuration.

Je ne suis pas d'accord avec toi, le projet de ma dll à un app.config aprés avoir référencé mon service et les sites web ont un web.config.

Ca n'aurait pas de sens de définir la configuration d'une DLL, vu que la DLL pourrait être utilisée par d'autres exécutables qui auraient besoin d'une configuration différente.

Dans mon cas toto.dll.config est quand même propre à ma dll puisque c'est elle qui contient la référence du service. Je ne trouve pas normal qu'il ne sache pas faire le lien entre toto.dll et toto.dll.config d'autant plus que c'est lui qui génère ce fameux fichier.config. Il devrait être en mesure de regarder si un fichier de configuration existe à l'emplacement de ma dll et pour ma dll et le charger en conséquence Au moins dans le cas d'une référence indirecte pour un fichier de config wcf.

Ca signifie que si par exemple je veux fournir un sdk à un de mes clients pour qu'il puisse exploiter mon service, je vais devoir lui fournir ma dll (mon sdk) et son fichier.config associé qu'il va devoir renommé en app.config et glisser dans son projet. Je ne trouve pas ça intuitif du tout et à mon avis il y a un manque de ce côté là.

Je ne peux même pas envisager de lui fournir un kit qui installerais ce sdk sur son poste (dll + dll.config) ou il aurait juste à ajouter la référence de ce sqk à son projet puisque .net n'est pas capable de charger cette dll.config associé

Le fichier de conf que tu as pour ta DLL doit être fusionné avec celui de l'exécutable qui utilise la DLL.

Comment fait tu ça ?

[tomlev]

Je ne suis pas d'accord avec toi, le projet de ma dll à un app.config aprés avoir référencé mon service et les sites web ont un web.config.

Oui je sais, mais comme je l'ai dit, c'est juste Visual Studio qui le crée pour que tu aies une conf de base, à intégrer dans la conf de l'exe. Si tu ne fais rien, il ne sera pas utilisé

Dans mon cas toto.dll.config est quand même propre à ma dll puisque c'est elle qui contient la référence du service. Je ne trouve pas normal qu'il ne sache pas faire le lien entre toto.dll et toto.dll.config d'autant plus que c'est lui qui génère ce fameux fichier.config. Il devrait être en mesure de regarder si un fichier de configuration existe à l'emplacement de ma dll et pour ma dll et le charger en conséquence

Au moins dans le cas d'une référence indirecte pour un fichier de config wcf

J'admets que ce raisonnement se tient... mais ce n'est pas comme ça que ça fonctionne

Comment fait tu ça ?

Ben tu mets le contenu de l'élément racine (<configuration>) du fichier de conf de la DLL dans l'élément racine du fichier de conf de l'exe (en fusionnant également les noeuds enfants si besoin)

[EmacLi]

Ben tu mets le contenu de l'élément racine (<configuration>) du fichier de conf de la DLL dans l'élément racine du fichier de conf de l'exe (en fusionnant également les noeuds enfants si besoin)

C'est ce que j'avais déjà fait, je pensais qu'il y avait une manip pour faire ça automatiquement à la référence de la dll ce qui aurait résolu mon pb.

Merci pour toutes ce informations.