Dienstreferenzfehler: Fehler beim Generieren des Codes für die Dienstreferenz

Ich habe eine Windows-Dienstlösung und versuche, einen Dienstverweis auf einen Hermes-Webdienst (Opensource ebms message server) in VS2010 hinzuzufügen.

Ich kann den Webdienst anhand seiner URL finden, aber wenn ich versuche, die Dienstreferenz auszufüllen, werden in Visual Studio die folgenden Fehler angezeigt:

Error 8 Custom tool error: Failed to generate code for the service reference 'testService'.  Please check other error and warning messages for details. C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler


Warning 6 Custom tool warning: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on.
XPath to wsdl:portType: //wsdl:definitions[@targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:portType[@name='EbmsStatusQuery']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:binding[@name='EbmsSoapHttpStatusQuery'] C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler

Warning 7 Custom tool warning: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
XPath to wsdl:binding: //wsdl:definitions[@targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:binding[@name='EbmsSoapHttpStatusQuery']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:service[@name='EbmsMessageStatusQuery']/wsdl:port[@name='EbmsStatusQuery'] C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler

Warning 5 Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.XmlSerializerMessageContractImporter
Error: Schema with target namespace 'http://service.ebms.edi.cecid.hku.hk/' could not be found.
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://service.ebms.edi.cecid.hku.hk/']/wsdl:portType[@name='EbmsStatusQuery'] C:\Users\Admin\documents\visual studio 2010\Projects\MyProject\MyProject.MessageHandler\Service References\testService\Reference.svcmap 1 1 MyProject.MessageHandler

Einige Untersuchungen schienen darauf hinzudeuten, dass svcutil.exe die Proxys nicht erstellen konnte, da keine Berechtigungen für ein Verzeichnis (möglicherweise c: \ windows \ temp) vorhanden waren. Ich habe versucht, verschiedene Zugriffsberechtigungen zuzuweisen, bin mir jedoch nicht sicher, welcher Benutzer die Berechtigung benötigt oder ob es sich nur um einen roten Hering handelt.

Irgendwelche Ideen wären sehr dankbar.

Vielen Dank

Deaktivieren Sie die Option Wiederverwendungstypen in allen Assemblys, auf die verwiesen wird, unter der Option Dienstreferenz konfigurieren

Überprüfen Sie dies für Details

Klicken Sie mit der rechten Maustaste auf Ihre Servicereferenz und wählen Sie Configure Service Reference...

Dann deaktivieren Sie Reuse types in referenced assemblies

Klicken Sie auf OKIhre Lösung, bereinigen Sie sie und erstellen Sie sie neu.

Beim Versuch, den Client für einen Webdienst aus einem ASP .Net MVC 4.0-Projekt mit Visual Studio 2012 zu generieren, ist ein ähnlicher Fehler aufgetreten.

Die Wurzel des Problems scheint die Tatsache zu sein, dass das Projekt, aus dem ich den Client generieren wollte, auf eine Assembly verweist, die wiederum von einer anderen Assembly abhängig ist, auf die ebenfalls nicht verwiesen wird.

Wenn in der Servicekonfiguration "Typen in referenzierten Assemblys wiederverwenden" aktiviert ist, überprüft der Servicegenerator wahrscheinlich alle referenzierten Assemblys, um eine Liste der Typen zu erhalten, die wiederverwendet werden können. Die Tatsache, dass eine der referenzierten Assemblys auf eine andere Assembly verweist, die nicht verfügbar ist, führt wahrscheinlich zum Ausfall des Generators.

Durch Deaktivieren von "Wiederverwendungstypen in Assemblys, auf die verwiesen wird" in den Dienstkonfigurationen wird das oben genannte Problem behoben , es gibt jedoch einen Nebeneffekt. Die Option für Wiederverwendungstypen gibt es aus einem bestimmten Grund und in einigen Fällen wird unnötiges Umwandeln des Codes vermieden, der den Dienst verbraucht.

Wenn der Dienst selbst mit WCF erstellt wird und einige darin enthaltene Methodenparameter vom Typ System.Guid sind, werden sie im generierten Client in Zeichenfolgen übersetzt, wenn die Option für Wiederverwendungstypen deaktiviert ist.

Eine Alternative, die ich lieber deaktiviere, ist das Hinzufügen der Dienstreferenz aus dem speziell für diesen Zweck erstellten Klassenbibliotheksprojekt. Beachten Sie, dass Sie alle dienstbezogenen Konfigurationen aus der app.config der Klassenbibliothek in die Konfigurationsdatei des Startprojekts kopieren müssen.

Wenn in lokalen Assemblys Typen definiert sind, die im Service-Client wiederverwendet werden müssen, müssen diese Assemblys zusammen mit all ihren Abhängigkeiten einfach aus dem oben genannten Klassenbibliotheksprojekt referenziert werden.

http://uliasz.com/2011/06/wcf-custom-tool-error-failed-to-generate-code-for-the-service-reference/#comment-1647

Danke an den obigen Artikel.

In meinem Fall habe ich dieses Problem mit meinem WPF-Projekt in VS.Net 2008. Nachdem ich diesen Artikel durchgesehen hatte, stellte ich fest, dass die im Webdienst verwendete Assembly eine andere Version der auf dem Client verwendeten Assembly ist.

Es funktioniert einwandfrei, nachdem die Assembly auf dem Client aktualisiert wurde.

Es wäre äußerst schwierig, das Problem zu erraten, da es auf einen Fehler in der WSDL zurückzuführen ist. Ohne Prüfung der WSDL kann ich nicht viel mehr kommentieren. Wenn Sie also Ihre WSDL teilen können, tun Sie dies bitte.

Ich kann nur sagen, dass in der WSDL anscheinend ein Schema fehlt (mit dem Zielnamespace 'http://service.ebms.edi.cecid.hku.hk/'). Ich kenne Probleme und die unterschiedliche Behandlung des Schemas, wenn Include-Anweisungen ignoriert werden.

Im Allgemeinen fand ich die Implementierung von Webdiensten durch Microsoft ziemlich gut, daher denke ich, dass der Webdienst zwielichtige WSDL zurücksendet.

Ich erhalte den gleichen Fehler in Silverlight 5 (VS2012)

Sie können auch die Verweise auf Folgendes entfernen:

• System.ServiceModel.DomainServices.Client
• System.ServiceModel.DomainServices.Client.Web

Nachdem Sie die Dienstreferenzen aktualisiert haben, müssen Sie sie wieder hinzufügen.

Wie oben erwähnt, sind verschiedene Probleme möglich. Wir haben festgestellt, dass die DLL für die WCF-Bibliothek als Referenz zum Client-Projekt hinzugefügt wurde. Dies führte wiederum zu Problemen beim Auflösen der Objekte und führte dazu, dass die Dateien durch Schritte zur Codegenerierung "geleert" wurden. Das Deaktivieren der Option "Wiederverwendungstypen ..." kann als Antwort erscheinen, erstellt jedoch zusätzliche Definitionen von Objekttypen, die Proxys für die realen Typen sind, in einem neuen Namensraum, wodurch alle Arten von "Kompatibilitätsproblemen" verursacht werden die Verwendung dieser Typen. Nur wenn Sie einen Typ wirklich "ausblenden" möchten, sollten Sie diese Option aktivieren.

Das Ausblenden des Typs ist angemessen, wenn Sie nicht möchten, dass eine Abhängigkeit vom Typ "DLL" in ein Projekt "leckt", das Sie von einem anderen getrennt halten möchten. Wenn sich die DLL für das WCF-Bibliotheksprojekt in die Client-Projektreferenzen einschleicht, tritt dieses Problem mit allen möglichen seltsamen Nebenwirkungen auf, da sich die Typdefinitionen auch in der DLL befinden.

Das gleiche Problem wurde behoben, indem Visual Studio im Admin-Modus ausgeführt wurde

Dieses Problem ist beim Upgrade einer VS2010 WCF + Silverlight-Lösung in VS2015 Professional aufgetreten . Neben dem automatischen Upgrade von Silverlight 4 auf Silverlight 5 wurde das Kontrollkästchen für die Wiederverwendung von Dienstreferenzen geändert und die Generierung fehlgeschlagen.

"Wiederverwendungstypen" ist nicht immer das Problem, wenn dieser Fehler auftritt.

Wenn Sie einen Verweis auf einen älteren Dienst hinzufügen, klicken Sie auf "Erweitert" und dort auf "Webreferenz hinzufügen". Verlinken Sie jetzt auf Ihre WSDL und alles sollte funktionieren.

Wenn Sie dies korrigieren möchten, ohne das Kontrollkästchen für die Wiederverwendung von Baugruppen zu deaktivieren, hat dies für mich funktioniert:

• Entfernen Sie die referenzierte Assembly, die Sie wiederverwenden möchten
• Löschen Sie den gesamten bin-Ordner des Projekts
• Servicereferenz aktualisieren
  • Behalten Sie "Wiederverwendungstypen in bestimmten Baugruppen bei, auf die verwiesen wird".
• Fügen Sie erneut einen Verweis auf die Baugruppe hinzu, um die Fehler zu beheben
• Aktualisieren Sie die Servicereferenz erneut

Der Neustart von Visual Studio hat den Trick für mich getan. Ich benutze VS 2015.

Ich hatte dieses Problem beim Versuch, meine Dienstreferenz zu aktualisieren (der Fehler wird jedoch nur beim Hinzufügen einer Dienstreferenz angezeigt), wollte aber das Kontrollkästchen für die Wiederverwendung von Baugruppen nicht entfernen.

Was für mich funktioniert hat, war Folgendes:

• Entfernen Sie die referenzierte Assembly, die ich wiederverwenden wollte
• Servicereferenz aktualisieren
• Behalten Sie "Wiederverwendungstypen in bestimmten Baugruppen bei, auf die verwiesen wird".
• Ignorieren Sie die Fehler, weil die Referenz fehlt!
• Fügen Sie erneut einen Verweis auf die Baugruppe hinzu, um die Fehler zu beheben
• Aktualisieren Sie die Servicereferenz erneut

Voila, jetzt wird es tatsächlich aktualisiert und versucht nicht mehr, meinen gesamten generierten Code zu entfernen.

Ich war fast bereit, die Funktion für Wiederverwendungstypen aufzugeben ...

BEARBEITEN: Stellen Sie außerdem sicher, dass die Build-Konfiguration AnyCPU oder x86 ist, da svcutil mit x64 fehlerhaft ist.

An den Downvoter: Entschuldigung, wenn es bei Ihnen nicht funktioniert hat, ich weiß nicht einmal, warum es bei mir funktioniert hat, aber es hat funktioniert. Ich habe damals vielleicht etwas anderes getan, das das Problem behoben hat, aber jetzt keine Möglichkeit, es zu wissen.