WCF Rich Client - Problem mit mehreren Projekten

[heischo]

Hallo!

Ich habe 2 Anwendungsprojekte (Keine Web-Anwendungen!) und ein Class Library Projekt.
Letzeres beinhaltet eine Service Referenz auf einen (nicht eigenen) Webservice, und ist im Prinzip ein Wrapper.
Auch eine app.config ist dort definiert, mit endpoint address, binding, contract='WSDL.xyz', name='xyz_port' etc.

Die 2 Anwendungsprojekte haben ihrerseits eine Referenz auf die Class Library, und nutzen generell nur die Wrapper-Funktionen, nie jedoch direkt den Webservice.

Das Problem ist nun, dass ich generell eine Fehlermeldung erhalte, wenn ich eines der Anwendungsprogramme starte, und dort dann mittels des Wrappers eine Client Instanz erstellt werden soll. Die Fehlermeldung ist: "Could not find endpoint element with name 'xyz_port' and contract 'WSDL.xyz' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this name could be found in the client element".
Alles sieht danach aus als ob die app.config im Wrapper-Projekt völlig sinnlos ist, sobald aus einem anderen Projekt heraus per Wrapper auf den Webservice-Client zugegriffen wird.

Was muss ich de facto tun damit die Anwendungsprojekte den Wrapper fehlerfrei benutzen können?
Gibt es einen "Trick" wie ich per code die Vorraussetzungen schaffen kann, ohne dass ich (wie ich vermute) pro Projekt eine komplette app.config generieren muss?

Mfg
Heiko S.

PS: Ich bin kein WCF Spezi, und habe schon einige Google Suchen hinter mir samt Stöbern im Handbuch der .NET Programmierung. Aber ich komme trotz allem nicht dahinter was hier falsch läuft ...

[Ralf Jansen]

Alles sieht danach aus als ob die app.config im Wrapper-Projekt völlig sinnlos ist, sobald aus einem anderen Projekt heraus per Wrapper auf den Webservice-Client zugegriffen wird.

Dem ist so. Executables haben config Dateien nicht Assemblies. Das eine Class Library auch ein ebekommt ist vermutlich eine Eigenheit des benutzten Visual Studio Designers.

Du kannst bestimmte Teile aus der app.config auslagern und per configSource Attribut referenzieren. Das bezieht sich aber immer auf die einzelne Sektion nicht auf eine ganze andere app.config. Die könnte ja dann auch wiedersprechliche Einstellungen zur der der Executable enthalten. Siehe zum Beispiel hier

[heischo]

Danke Ralf!

Ich habe in der Zwischenzeit weiter gesucht (mir lässt sowas keine Ruhe bis ich es wirklich 95%ig kapiert habe), und bin gerade eben über noch eine Alternative gestolpert:
Man kann in einem Projekt die app.config eines anderen Projektes als LINK einfügen.
Ergo habe ich die "originale" app.config weiterhin im Class Library Projekt, während die beiden Applikationen nur den Verweis besitzen.
So muss ich nur die EINE app.config abändern, aber alle Projekte kriegen diese Änderung sofort mit

Zumindest im Debugger funktioniert es auch praktisch. Wie es dann beim Publishing aussieht das ahne ich noch nicht ...

Also danke nochmal, ich sehe jetzt bedeutend klarer

[Ralf Jansen]

Spätestens wenn die Executables ihre eigenen Einstellungen brauchen ist das vorbei. Eine app.config zu haben die die Obermenge aller nötigen Einstellungen aller Executables ist geht nur solange wie alle die gleichen Einstellungen brauchen.

[heischo]

Ja das stimmt.
In meinem Fall sollte es eine Weile halten:
App1 ist ein WinForms-Setup welches eine eigene Konfigurationsdatei erstellt bzw. verwaltet, App2 ist eine Konsolenapp, die von der Konfigurationsdatei aus der App1 gefüttert wird.
Insofern brauche ich die app.config echt nur für den Webservice.
Wenn ich mehr Zeit hätte um mich tiefer einzuarbeiten würde ich auch die restlichen app.config Einstellungen gern in meine eigene Konfiguration übernehmen, und dann den ganzen <system.serviceModel> Abschnitt per Code "simulieren".

[fanderlf]

Sofern Du es dann auch tatsächlich umbaust wenn es soweit ist und man nicht aus Zeitgründen trotzdem irgendwelche furchtbaren Hacks rein baut ist das die Beste Lösung. Ich persönlich würde es jetzt auch nicht sooo schlimm finden die Endpoints zweimal in den einzelnen configs zu ändern. Je nachdem wie professionell das ist könnte es evtl. auch einen eigenen Buildstep geben oder man macht die Konfiguration im Code, sofern die Library das zulässt.