it-swarm.com.de

Das Standardendpunktelement konnte nicht gefunden werden

Ich habe einem Webservice einer VS2008/.NET 3.5-Lösung einen Proxy hinzugefügt. Beim Erstellen des Clients wird in .NET der folgende Fehler ausgegeben:

Das standardmäßige Endpunktelement, das auf den Vertrag "IMySOAPWebService" verweist, wurde im Abschnitt zur Konfiguration des ServiceModel-Clients nicht gefunden. Dies kann daran liegen, dass für Ihre Anwendung keine Konfigurationsdatei gefunden wurde oder dass im Client-Element kein Endpunktelement gefunden wurde, das diesem Vertrag entspricht.

Wenn ich nach diesem Fehler suche, soll ich den vollständigen Namespace im Vertrag verwenden. Hier ist meine app.config mit vollem Namespace:

<client>
  <endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
            binding="basicHttpBinding" bindingConfiguration="IMySOAPWebServicebinding"
            contract="Fusion.DataExchange.Workflows.IMySOAPWebService" name="IMySOAPWebServicePort" />
</client>

Ich verwende XP local (Ich erwähne dies, weil einige Google-Hits win2k3 erwähnen) Die app.config wird nach app.exe.config kopiert, also ist das auch nicht das Problem.

Irgendwelche Hinweise?

356
edosoft

Nachdem ich mehrere Optionen getestet hatte, löste ich dies mit

contract = "IMySOAPWebService"

d.h. ohne den vollständigen Namespace in der Konfiguration. Aus irgendeinem Grund wurde der vollständige Name nicht richtig aufgelöst

74
edosoft

"Dieser Fehler kann auftreten, wenn Sie den Dienst in einer Klassenbibliothek aufrufen und die Klassenbibliothek aus einem anderen Projekt aufrufen."

In diesem Fall müssen Sie die WS-Konfigurationseinstellungen in die Hauptprojekte app.config aufnehmen, wenn es sich um eine WinApp handelt, oder web.config, wenn es sich um eine Web-App handelt. Dies ist der richtige Weg, auch mit PRISM und WPF/Silverlight.

574
L.R.

Ich habe dieses Problem gelöst (ich glaube, wie andere vorgeschlagen haben), indem ich die Bindungs- und Endpunktadressinstanzen selbst erstellt habe, da ich den Konfigurationsdateien keine neuen Einstellungen hinzufügen wollte (dies ist ein Ersatz für vorhandenen Bibliothekscode, der häufig verwendet wird). und zuvor eine ältere Webdienstreferenz verwendet usw.), und so wollte ich in der Lage sein, dies zu löschen, ohne überall neue Konfigurationseinstellungen hinzuzufügen.

var remoteAddress = new System.ServiceModel.EndpointAddress(_webServiceUrl);

using (var productService = new ProductClient(new System.ServiceModel.BasicHttpBinding(), remoteAddress))
{
    //set timeout
    productService.Endpoint.Binding.SendTimeout = new TimeSpan(0,0,0,_webServiceTimeout);

    //call web service method
    productResponse = productService.GetProducts();
} 

Bearbeiten

Wenn Sie https verwenden, müssen Sie BasicHttpsBinding anstelle von BasicHttpBinding verwenden.

79
Tom Haigh

Ich hatte das gleiche Problem. Es stellt sich heraus, dass Sie für eine Web-REFERENZ die URL als ersten Parameter an den Konstruktor übergeben müssen:

new WebService.WebServiceSoapClient("http://myservice.com/moo.aspx");

Für eine Web-SERVICE-REFERENZ im neuen Stil müssen Sie einen Namen angeben, der auf einen Endpunkteintrag in der Konfiguration verweist:

new WebService.WebServiceSoapClient("WebServiceEndpoint");

Mit einem entsprechenden Eintrag in Web.config oder App.config:

<client>
      <endpoint address="http://myservice.com/moo.aspx"
        binding="basicHttpBinding" 
        bindingConfiguration="WebService"
        contract="WebService.WebServiceSoap"
        name="WebServiceEndpoint" />
    </client>
  </system.serviceModel>

Ziemlich schwer zu entfernen die Tunnel Vision auf "es hat in einem älteren Programm funktioniert" ...

54
Andomar

Ich hatte eine Situation wie diese, wo ich hatte

  • Irgendwo gehosteter WCF-Dienst
  • Hauptprojekt
  • Consumer-Projekt vom Typ "Klassenbibliothek", dessen Dienst auf einen WCF-Dienst verweist
  • Hauptprojekt ruft Methoden aus dem Consumer-Projekt auf

Jetzt hatte das Consumer-Projekt alle zugehörigen Konfigurationseinstellungen in <system.serviceModel> Tag meiner app.config, es gab immer noch den gleichen Fehler wie oben.

Alles, was ich getan habe, ist das gleiche Tag hinzugefügt <system.serviceModel> in die app.config-Datei meines Hauptprojekts, und endlich war es so weit.

Das eigentliche Problem war meines Erachtens das Lesen der falschen Konfigurationsdatei. Anstelle der app.config des Verbrauchers wurde auf die Konfiguration des Hauptproj verwiesen. Ich habe zwei Stunden gebraucht, um das herauszufinden.

16
Bravo

"Dieser Fehler kann auftreten, wenn Sie den Dienst in einer Klassenbibliothek aufrufen und die Klassenbibliothek aus einem anderen Projekt aufrufen."

"In diesem Fall müssen Sie die WS-Konfigurationseinstellungen in die Hauptprojekte app.config aufnehmen, wenn es sich um eine WinApp handelt, oder web.config, wenn es sich um eine Web-App handelt. Auf diese Weise können Sie auch mit PRISM und WPF/Silverlight arbeiten."

Ja, aber wenn Sie das Hauptprojekt (z. B. Orchard CMS) nicht ändern können, können Sie die WCF-Dienstkonfiguration in Ihrem Projekt beibehalten.

Sie müssen einen Service Helper mit der Methode zur Client-Generierung erstellen:

public static class ServiceClientHelper
{
    public static T GetClient<T>(string moduleName) where T : IClientChannel
    {
        var channelType = typeof(T);
        var contractType = channelType.GetInterfaces().First(i => i.Namespace == channelType.Namespace);
        var contractAttribute = contractType.GetCustomAttributes(typeof(ServiceContractAttribute), false).First() as ServiceContractAttribute;

        if (contractAttribute == null)
            throw new Exception("contractAttribute not configured");

        //path to your lib app.config (mark as "Copy Always" in properties)
        var configPath = HostingEnvironment.MapPath(String.Format("~/Modules/{0}/bin/{0}.dll.config", moduleName)); 

        var configuration = ConfigurationManager.OpenMappedExeConfiguration(new ExeConfigurationFileMap { ExeConfigFilename = configPath }, ConfigurationUserLevel.None);
        var serviceModelSectionGroup = ServiceModelSectionGroup.GetSectionGroup(configuration);

        if (serviceModelSectionGroup == null)
            throw new Exception("serviceModelSectionGroup not configured");

        var endpoint = serviceModelSectionGroup.Client.Endpoints.OfType<ChannelEndpointElement>().First(e => e.Contract == contractAttribute.ConfigurationName);
        var channelFactory = new ConfigurationChannelFactory<T>(endpoint.Name, configuration, null);
        var client = channelFactory.CreateChannel();
        return client;
    }
}

und benutze es:

using (var client = ServiceClientHelper.GetClient<IDefaultNameServiceChannel>(yourLibName)) {
                ... get data from service ...
            }

Siehe Details in dieser Artikel .

14
melvas

Dieser hat mich verrückt gemacht.

Ich verwende Silverlight 3 Prism (CAB) mit WCF

Wenn ich einen WCF-Dienst in einem Prism-Modul aufrufe, wird der gleiche Fehler angezeigt:

Das standardmäßige Endpunktelement, das auf den Vertrag "IMyService" verweist, wurde im Abschnitt zur Clientkonfiguration für das Servicemodell nicht gefunden. Dies kann daran liegen, dass für Ihre Anwendung keine Konfigurationsdatei gefunden wurde oder dass im Client-Element kein Endpunktelement gefunden wurde, das diesem Vertrag entspricht

Es stellt sich heraus, dass in der .xap-Datei der Shell nach einer ServiceReferences.ClientConfig-Datei gesucht wird, nicht in der ServiceReferences.ClientConfig-Datei des Moduls. Ich habe meinen Endpunkt und die Bindung zu der vorhandenen Datei "ServiceReferences.ClientConfig" in meiner Silverlight Shell-Anwendung hinzugefügt (sie ruft ihre eigenen WCF-Dienste auf).

Dann musste ich die Shell-App neu erstellen, um die neue XAP-Datei für den ClientBin-Ordner meines Webprojekts zu generieren.

Nun funktioniert diese Codezeile endlich:

MyServiceClient myService = new MyServiceClient();
12
Jeff Moeller

Mehrere Antworten hier treffen auf die richtige Lösung, wenn Sie auf den irrsinnig obskuren Fehler stoßen, auf den Dienst aus einer Klassendatei zu verweisen: Kopieren Sie die Dienstkonfigurationsinformationen in die Datei app.config web.config Ihrer Konsole oder Windows-App. Keine dieser Antworten scheint Ihnen zu zeigen, was Sie kopieren sollen. Versuchen wir das zu korrigieren.

Folgendes habe ich aus der Konfigurationsdatei meiner Klassenbibliothek in die Konfigurationsdatei meiner Konsolenanwendung kopiert, um diesen verrückten Fehler für einen Dienst namens "TranslationServiceOutbound" zu umgehen.

Grundsätzlich möchten Sie alles im Abschnitt system.serviceModel:

  <system.serviceModel>
<bindings>
  <basicHttpBinding>
    <binding name="BasicHttpBinding_ITranslationServiceOutbound" />
  </basicHttpBinding>
</bindings>
<client>
  <endpoint address="http://MyHostName/TranslationServiceOutbound/TranslationServiceOutbound.svc"
    binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ITranslationServiceOutbound"
    contract="TranslationService.ITranslationServiceOutbound" name="BasicHttpBinding_ITranslationServiceOutbound" />
</client>
12
markaaronky

Ich habe diesen Fehler in einer ASP.NET-Anwendung erhalten, in der der WCF-Dienst einer Klassenbibliothek hinzugefügt wurde, die der ASP.NET-Anwendung als referenzierte DLL-Datei im Ordner bin hinzugefügt wird. Um den Fehler zu beheben, mussten die Konfigurationseinstellungen in der Datei app.config in der Klassenbibliothek, die auf den WCF-Dienst verweist, in die web.config-Einstellungen für die ASP.NET-Site/-App kopiert werden.

11
zanderwel

Ich fand (sowie das Kopieren in die App.config der Client-Benutzeroberfläche, da ich eine Klassenbibliotheksschnittstelle verwendete), dass ich dem Namen der Bindung den Namen der Dienstreferenz voranstellen musste (meine ist ServiceReference in der unten).

z.B.:

<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
      bindingConfiguration="BasicHttpBinding_ISchedulerService"
      contract="ServiceReference.ISchedulerService" 
      name="BasicHttpBinding_ISchedulerService" />

anstelle der Standardeinstellung generiert:

<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
      bindingConfiguration="BasicHttpBinding_ISchedulerService"
      contract="ISchedulerService" 
      name="BasicHttpBinding_ISchedulerService" />
9
Matt Mitchell

Ich hatte das gleiche Problem, aber das Ändern des Vertragsnamensraums funktionierte bei mir nicht. Daher habe ich eine .Net 2-Webreferenz anstelle einer .Net 3.5-Dienstreferenz ausprobiert. Das hat funktioniert.

Um einen Webverweis in Visual Studio 2008 zu verwenden, klicken Sie auf "Dienstverweis hinzufügen" und dann auf "Erweitert", wenn das Dialogfeld angezeigt wird. Darin finden Sie eine Option, mit der Sie einen Webverweis anstelle eines Dienstverweises verwenden können.

7
Cyril Gupta

Ich habe eine Situation, die im Unit-Test. Ich habe die Datei app.config in das Unit-Test-Projekt kopiert. Das Unit-Test-Projekt enthält also auch Endpunktinformationen.

6
user1108948

Unit-Tests einer Nicht-Bibliotheksanwendung, die einen Dienst verwendet, können dieses Problem verursachen.

Die Informationen, die andere eingegeben haben, sind die Hauptursache dafür. Wenn Sie versuchen, automatisierte Testfälle zu schreiben, und die Einheit, die Sie testen, tatsächlich die Serviceschnittstelle aufruft, müssen Sie die Servicereferenz zum Testprojekt hinzufügen. Dies ist eine Variante der Anwendung, die den Fehlertyp Bibliothek verwendet. Ich habe dies jedoch nicht sofort bemerkt, da mein Code, der die Schnittstelle belegt, nicht in einer Bibliothek enthalten ist. Wenn der Test jedoch tatsächlich ausgeführt wird, wird er von der Test-Assembly ausgeführt, nicht von der zu testenden Assembly.

Das Hinzufügen einer Servicereferenz zum Komponententestprojekt hat mein Problem gelöst.

6
PatrickV

Ich war einmal mit diesem Problem konfrontiert. Es war, weil ich noch die Schnittstelle entwickelte, die WCF-Dienst verwendet. Ich habe die Testanwendung konfiguriert und weiterentwickelt. Dann habe ich in der Entwicklung einige Namespaces der Services geändert. Also habe ich "system.serviceModel -> client -> endpoint -> contract" in web.config doppelt überprüft, um der WCF-Klasse zu entsprechen. Dann ist das Problem gelöst.

4
vardars

Nur für alle, die das gleiche Problem haben. Ich habe einen Komponententest für meine Methode geschrieben, bei dem versucht wurde, eine Verbindung zu meinem Dienst herzustellen. Es ist jedes Mal mit der gleichen Ausnahme gescheitert - ich habe keine Ahnung warum. Wenn ich es von einer Winform lief, funktioniert es gut.

3
PhilG

Der Namespace in Ihrer Konfiguration sollte den Rest des Namespace-Pfads nach dem Standardnamespace Ihres Clients widerspiegeln (wie in den Projekteigenschaften konfiguriert). Ausgehend von Ihrer Antwort gehe ich davon aus, dass Ihr Client so konfiguriert ist, dass er sich im Namespace "Fusion.DataExchange.Workflows" befindet. Wenn Sie den Client-Code in einen anderen Namespace verschoben haben, müssen Sie die Konfiguration aktualisieren, damit sie mit dem verbleibenden Namespace-Pfad übereinstimmt.

3
Chris Porter

Hallo, ich bin auf das gleiche Problem gestoßen, aber die beste Lösung besteht darin, das .NET Ihre clientseitige Konfiguration konfigurieren zu lassen. Ich stelle fest, dass beim Hinzufügen eines Dienstverweises mit der Abfragezeichenfolge http: /namespace/service.svc? Wsdl = wsdl0 KEINE Konfigurationsendpunkte auf der Clientseite erstellt werden. Wenn ich jedoch das? Wsdl-wsdl0 entferne und nur die URL http: /namespace/service.svc verwende, wird die Endpunktkonfiguration in der Client-Konfigurationsdatei erstellt. kurz remoe die "? WSDL = WSDL0".

2
Joey

Platzieren Sie die Service-Client-Deklarationszeile nicht als Klassenfeld, sondern erstellen Sie stattdessen bei jeder verwendeten Methode eine Instanz. Das Problem wird behoben. Wenn Sie eine Service-Client-Instanz als Klassenfeld erstellen, tritt ein Entwurfszeitfehler auf!

2
Mücahid Uslu

Wenn Sie eine WPF-Anwendung mit PRISM-Framework verwenden, sollte die Konfiguration in Ihrem Startprojekt vorhanden sein (d. H. In dem Projekt, in dem sich Ihr Bootstrapper befindet).

2
VRK

Wenn Sie auf den Webdienst in Ihrer Klassenbibliothek verweisen, müssen Sie app.config in Ihre Windows-Anwendung oder Konsolenanwendung kopieren

lösung: Ändern Sie die Konfiguration des äußeren Projekts entsprechend der wcf-Konfiguration der Klassenbibliothek.

Hat für mich gearbeitet

2
Roshan

Es gibt verschiedene Möglichkeiten, dieses Problem zu beheben. Für mich ist das CRM-Produkt, das ich verwende, in nativem Code geschrieben und kann meine .NET-DLL aufrufen, aber ich stoße auf die Konfigurationsinformationen, die sich in/über der Hauptanwendung befinden müssen. Für mich ist die CRM-Anwendung nicht .NET, daher musste ich sie in meine Datei machine.config einfügen (nicht dort, wo ich sie haben möchte). Da mein Unternehmen Websense verwendet, fiel es mir außerdem schwer, die Dienstreferenz hinzuzufügen, da ein Problem mit der 407-Proxy-Authentifizierung aufgetreten ist, das eine Änderung der Datei machine.cong erforderlich machte.

Proxy-Lösung:

Damit die WCF-Dienstreferenz funktioniert, musste ich die Informationen aus der app.config von meiner DLL in die Hauptanwendungskonfiguration kopieren (aber für mich war das machine.config). Und ich auch Ich musste die Endpunktinformationen in dieselbe Datei kopieren, und als ich das tat, funktionierte es für mich.

1
TPaul

Ich hatte das gleiche Problem
Ich habe die Desktop-App und den Global Weather-Webdienst verwendet

Ich habe die Servicereferenz gelöscht und die Webreferenz hinzugefügt und das Problem behoben. Danke

1
Kamran Akhter

Dieser Fehler kann auftreten, wenn Sie den Dienst in einer Klassenbibliothek aufrufen und die Klassenbibliothek aus einem anderen Projekt aufrufen.

1
Manuel Alves

Ich hatte diesen Fehler, als ich auf den Vertrag im Konfigurationsdateielement ohne den globalen Bereichsoperator verwies.

d.h.

<endpoint contract="global::MyNamepsace.IMyContract" .../>

funktioniert, aber

<endpoint contract="MyNamepsace.IMyContract" .../>

gibt den Fehler "Standard-Endpunktelement, das auf Vertrag verweist, konnte nicht gefunden werden" aus.

Die Assembly mit MyNamepsace.IMyContract befindet sich in einer anderen Assembly als die Hauptanwendung. Dies erklärt möglicherweise die Notwendigkeit, die globale Bereichsauflösung zu verwenden.

1
saille

Gestatten Sie mir, noch eine Sache hinzuzufügen, nach der ich suchen muss. ( Tom Haighs Antwort spielt bereits darauf an, aber ich möchte explizit sein)

Mein web.config Datei hatte die folgenden definiert:

<protocolMapping>
    <add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>

Ich habe basicHttpsBinding bereits für eine Referenz verwendet, dann aber eine neue Referenz hinzugefügt, für die basicHttpBinding (no s) erforderlich ist. Ich musste das nur wie folgt zu meinem protocolMapping hinzufügen:

<protocolMapping>
    <add binding="basicHttpBinding" scheme="http" />
    <add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>

Wie L.R. richtig anzeigt, muss dies an den richtigen Stellen definiert werden. Für mich bedeutete dies sowohl eine in der app.config meines Unit-Test-Projekts als auch eine in der web.config meines Hauptdienstprojekts.

1
David

Ich habe den gleichen Fehler bekommen und ich habe einige Dinge ausprobiert, aber es hat nicht funktioniert. Dann habe ich festgestellt, dass mein "Vertrag" nicht für ganze Projekte gleich war. Dies ist Projekt A

<client>
    <endpoint address="https://xxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference.IIntegrationService" name="basic" />
</client>

Projekt B:

<client>
    <endpoint address="xxxxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference1.IIntegrationService" name="basic" />
</client>

Schließlich habe ich für beide geändert als:

<client>
    <endpoint address="https://xxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="MyServiceReferrence.IIntegrationService" name="basic" />
</client>
1
nzrytmn

Für mich bestand die Lösung darin, den Endpunktnamen aus dem Endpunktnamen-Attribut in der Client-Datei web.config zu entfernen. Dadurch konnte der Proxy verwendet werden

ChannelFactory<TService> _channelFactory = new ChannelFactory<TService>("");

es dauerte nur den ganzen Tag, um zu trainieren. Auch der Vertragsname war falsch, als dieses Update installiert war, obwohl er falsch war, als der anfängliche Fehler auftrat. Verdoppeln Sie dann dreifache Kontrolle für Vertragsnamenszeichenkettenleute !! attrib: Ian

1
rob

Okay. Mein Fall war ein wenig anders, aber schließlich habe ich das Update dafür gefunden: Ich habe eine Console.EXE -> DLL -> Aufrufen von WS1 -> DLL -> WS2 aufrufen

Ich hatte beide Konfigurationen des Dienstmodells von WS1 und WS2 in der Console.EXE.config als empfohlen. - hat das Problem nicht gelöst.

Aber es hat immer noch nicht funktioniert, bis ich auch das WebReference von WS2 zu WS1 hinzugefügt habe und nicht nur das DLL), das den Proxy von WS2 tatsächlich erstellt und aufruft .

1
Itay Levin

Wenn Sie eine Servicereferenz hinzufügen

enter image description here

achten Sie auf den Namespace, den Sie eingeben:

enter image description here

Sie sollten es an den Namen Ihrer Schnittstelle anhängen:

<client>
  <endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
            binding="basicHttpBinding" 
            contract="MyNamespace.IMySOAPWebService" />
</client>

In meinem Fall bezog ich diesen Service aus einem Rahmenprojekt. Nachdem ich den Abschnitt in die Konfiguration des Hauptstartprojekts kopiert hatte, wurde das Problem behoben.

0
Nikhil Dinesh

Ich hatte das gleiche Problem und es wurde nur behoben, wenn die Host-Anwendung und die DLL, die diesen Endpunkt verwendeten, denselben Dienstreferenznamen hatten.

0
silver