HEUREKA ... ich habe das Problem gelöst. Auf dem Weg dahin habe ich unglaublich viel gelesen und gelernt. Für alle, die sich das ersparen wollen, zege ich hier die gefundene Lösung auf, die sowas von simple ist ...
Also:
Dem Silverlight-Projekt wird beim Hinzufügen eines Dienstverweises auf den zuvor erstellten WCF-Service von VS2010
automatisch eine Datei namens ServiceReferences.ClientConfig hinzugefügt. Damit hat es folgendes auf sich:
Bevor ich die Lösung fand, habe ich immer nur in der Web.Config-Datei des .Web-Projekts, und dort an der Endpoint-Adresse herumgewerkelt. Das war zur Lösung meines konkreten Problems völliger Quatsch. In der Web.config des
.Web-Projekts muss zwar vor dem Veröffentlichen der relative Pfad zum Service auf dem Server eingetragen werden. Das ist aber nícht das Ende vom Lied. Denn der Client, der ja nach dem Herunterladen der .xap-Datei vom Server unabhängig arbeitet,
muss ja beim Aufruf des proxy die Adresse zum Service mitbekommen. Und diese Adresse bekommt der Client nicht aus der Web.config (wie denn auch, denn die liegt ja auf dem Server), sondern von der besagten Datei
ServiceReferences.ClientConfig. In dieser Datei gibt es im <client>-Tag ebenfalls ein <endpoint>-Tag, und in diesem <endpoint>-Tag ein adress-Attribut.
Das Problem ist, wenn man in der Web.config die relative Server-Adresse des Services eingibt, dann mit Rechtklick im Silverlight-Projekt auf BeispielServiceReference -> Dienstverweis aktualisieren klickt, wird
nicht automatisch die Referenz in der Datei ServiceReferences.ClientConfig angepaßt. D.h., in der Datei
ServiceReferences.ClientConfig steht auch nach dem Aktualisieren des Dienstverweises im <endpoint>-Tag weiterhin die Adresse des lokalen Hosts der Debug-Umgebung, also sowas wie:
<endpoint adress="http://localhost:49380/BeispielService.svc" ... >
Die Lösung besteht darin, dass man vor dem endgültigen Veröffentlichen des Projekts auf dem Webserver den Wert des Attributs adress in der Datei
ServiceReferences.ClientConfig auf die Server-Zieladresse des Services ändert. Und das geht am Besten so:
Nachdem in der Web.config als Endpoint-Adresse die relative Adresse des Services auf dem Server korrekt angegeben wurde, dann der Dienstverweis (s.o.) aktualisiert wurde, sowohl das .Web-Projekt als auch das Silverlight-Projekt neu erstellt wurden, sollte
das Projekt einmal mit Rechtsklick auf das .Web-Projekt -> Veröffentlichen ... auf den Webserver veröffentlicht werden. Dann ruft man den Service durch direkte Ansprache in der URL einmal direkt auf, also z.B. mit
www.meineDomain.de/BeispielService.svc
Wenn der Service korrekt funktioniert, was man durch den direkten Aufruf vorteilhafterweise gleich mitrpüfen kann, erscheint eine Standard-Seite mit Information zum Service. Bestandteil dieser Seite ist ein URL zum Service. Um im Beispiel zu bleiben
würde dies lauten:
http://www.meineDomain.de/BeispielService.svc?wsdl
Auf diesen Link klickt man, und erhält dann den Inhalt die wsdl-Referenzdaten zum Service. Darin sieht man im <soap>-Tag den Wert des Attributs adress location:
- <wsdl:service name="BeispielService">
- <wsdl:port name="BasicHttpBinding_BeispielService" binding="tns:BasicHttpBinding_BeispielService">
<soap:address location="http://www.meineDomain.de/BeispielService.svc" />
</wsdl:port>
</wsdl:service>
Diesen Wert der adress location kopiert man und fügt ihn in der Datei
ServiceReferences.ClientConfig im <client><endpoint>-Tag als Wert des Attributs adress ein.
Die Projektmappe schließlich nochmals neu erstellen und dann das Projekt erneut veröffentlichen.
Und zack ... der Service funktioniert nun auch in der Wildnis.
Wie gesagt, der Weg zur Lösung dieses Problems war wirklich extrem leerreich. Ich hoffe, dass allen, die einmal vor dem gleichen Problem stehen, mit meinen Hinweisen etwas geholfen ist.
