Standardendpunktelement konnte nicht gefunden werden

Ich habe einem Webservice einer VS2008 / .NET 3.5-Lösung einen Proxy hinzugefügt. Beim Erstellen des Clients löst .NET den folgenden Fehler aus:

Das Standardendpunktelement, das auf den Vertrag 'IMySOAPWebService' verweist, konnte im Abschnitt "ServiceModel-Clientkonfiguration" nicht gefunden werden. 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, muss 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-Treffer win2k3 erwähnen). Die app.config wird in app.exe.config kopiert, sodass dies auch nicht das Problem ist.

Irgendwelche Hinweise?

"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 auch mit PRISM und WPF / Silverlight der richtige Weg.

Ich habe dieses Problem gelöst (ich denke, wie andere vielleicht vorgeschlagen haben), indem ich die Bindungs- und Endpunktadressinstanzen selbst erstellt habe - weil ich den Konfigurationsdateien keine neuen Einstellungen hinzufügen wollte (dies ist ein Ersatz für einen vorhandenen Bibliothekscode, der weit verbreitet ist). und zuvor eine ältere Webdienstreferenz usw. verwendet), und deshalb wollte ich diese ablegen können, ohne überall neue Konfigurationseinstellungen hinzufügen zu müssen.

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 BasicHttpsBindingstatt verwenden BasicHttpBinding.

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

contract = "IMySOAPWebService"

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

Ich hatte das gleiche Problem. Es stellt sich heraus, dass Sie für eine Web-REFERENZ die URL als ersten Parameter für den Konstruktor angeben 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.configoder App.config:

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

Es ist verdammt schwer, die Tunnelvision zu entfernen, wenn "es in einem älteren Programm funktioniert hat" ...

Ich hatte eine Situation wie diese, in der ich hatte

• WCF-Service irgendwo gehostet
• Hauptprojekt
• Verbraucherprojekt vom Typ 'Klassenbibliothek', das einen Dienstverweis auf einen WCF-Dienst enthält
• Das Hauptprojekt ruft Methoden aus dem Verbraucherprojekt auf

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

Alles, was ich getan habe, ist das gleiche Tag <system.serviceModel>zur app.config-Datei meines Hauptprojekts hinzugefügt, und schließlich konnten wir loslegen.

Das eigentliche Problem war, soweit in meinem Fall, das Lesen der falschen Konfigurationsdatei. Anstelle der app.config des Verbrauchers wurde auf die Konfiguration des Hauptprojekts verwiesen. Ich habe zwei Stunden gebraucht, um das herauszufinden.

"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."

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

Sie müssen einen Service-Helfer mit der Client-Generierungsmethode 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 diesem Artikel .

Mehrere Antworten hier haben die richtige Lösung gefunden, wenn Sie auf den unglaublich dunklen Fehler stoßen, den Dienst aus einer Klassendatei zu referenzieren: Kopieren Sie die Dienstkonfigurationsinformationen in Ihre app.config web.config Ihrer Konsole oder Windows-App. Keine dieser Antworten scheint Ihnen jedoch zu zeigen, was Sie kopieren müssen. Versuchen wir das zu korrigieren.

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

Sie möchten im Grunde 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>

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 Standardendpunktelement, das auf den Vertrag 'IMyService' verweist, konnte im Abschnitt zur Konfiguration des Servicemodellclients nicht gefunden werden. Dies kann daran liegen, dass für Ihre Anwendung keine Konfigurationsdatei gefunden wurde oder dass im Client-Element kein Endpunktelement gefunden werden konnte, 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 hinzugefügt und an die vorhandene Datei "ServiceReferences.ClientConfig" in meiner Silverlight Shell-Anwendung gebunden (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.

Jetzt funktioniert diese Codezeile endlich:

MyServiceClient myService = new MyServiceClient();

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 verweisen, in die Einstellungen web.config für die ASP.NET-Site / -App kopiert werden.

Ich stellte fest (und kopierte in die App.config der Client-Benutzeroberfläche, als ich eine Klassenbibliotheksschnittstelle verwendete), dass ich dem Namen der Bindung den Namen der Dienstreferenz voranstellen musste (meiner ist ServiceReferenceunten).

z.B:

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

anstelle der generierten Standardeinstellung:

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

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

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

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

Die Informationen, die andere eingegeben haben, adressieren 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 dem Testprojekt die Servicereferenz hinzufügen. Dies ist eine Variante der Anwendung, bei der der Fehlertyp der Bibliothek verwendet wird. Ich habe dies jedoch nicht sofort bemerkt, da sich mein Code, der die Schnittstelle verwendet, nicht in einer Bibliothek befindet . Wenn der Test tatsächlich ausgeführt wird, wird er jedoch von der Testbaugruppe ausgeführt, nicht von der zu testenden Baugruppe.

Das Hinzufügen einer Servicereferenz zum Unit-Test-Projekt hat mein Problem behoben.

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.

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 der Namespaces der Dienste 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.

Der Namespace in Ihrer Konfiguration sollte den Rest des Namespace-Pfads nach dem Standard-Namespace Ihres Clients widerspiegeln (wie in den Projekteigenschaften konfiguriert). Aufgrund Ihrer veröffentlichten Antwort schätze ich, dass Ihr Client so konfiguriert ist, dass er sich im Namespace "Fusion.DataExchange.Workflows" befindet. Wenn Sie den Clientcode in einen anderen Namespace verschoben haben, müssen Sie die Konfiguration so aktualisieren, dass sie mit dem verbleibenden Namespace-Pfad übereinstimmt.

Ich habe das gleiche Problem. Ich verwende den WCF-Dienst in der Klassenbibliothek und rufe die Klassenbibliothek aus dem Windows-Anwendungsprojekt auf. Aber ich vergesse die Änderung <system.serviceModel>in der Konfigurationsdatei des Windows-Anwendungsprojekts genauso wie die <system.serviceModel>App.Config-Datei der Klassenbibliothek.
Lösung: Ändern Sie die Konfiguration des äußeren Projekts genauso wie die wcf-Konfiguration der Klassenbibliothek.

Hallo, ich habe das gleiche Problem festgestellt, aber die beste Lösung besteht darin, .NET Ihre clientseitige Konfiguration konfigurieren zu lassen. Wenn ich eine Dienstreferenz mit der Abfragezeichenfolge http: /namespace/service.svc? Wsdl = wsdl0 hinzufüge, werden auf der Clientseite KEINE Konfigurationsendpunkte erstellt. Wenn ich jedoch? Wsdl-wsdl0 entferne und nur die URL http: /namespace/service.svc verwende, wird die Endpunktkonfiguration in der Clientkonfigurationsdatei erstellt. für kurze remoe die "? WSDL = WSDL0".

Fügen Sie die Service-Client-Deklarationszeile nicht als Klassenfeld ein, sondern erstellen Sie stattdessen eine Instanz für jede Methode, die in verwendet wird. Das Problem wird also behoben. Wenn Sie eine Service-Client-Instanz als Klassenfeld erstellen, tritt ein Entwurfszeitfehler auf!

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

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

Es scheint verschiedene Möglichkeiten zu geben, dieses Problem zu erstellen / zu beheben. Für mich wurde das von mir verwendete CRM-Produkt 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 aufgrund eines Problems mit der erforderlichen 407-Proxy-Authentifizierung hinzuzufügen, das eine Änderung an machine.cong erforderlich machte.

Proxy-Lösung:

Damit die WCF-Dienstreferenz funktioniert, musste ich die Informationen aus der app.config meiner DLL in die Hauptanwendungskonfiguration kopieren (für mich war das jedoch machine.config). Außerdem musste ich die Endpunktinformationen in dieselbe Datei kopieren. Sobald ich das getan habe, fing es an, für mich zu arbeiten.

OK. Mein Fall war etwas anders, aber schließlich habe ich die Lösung dafür gefunden: Ich habe eine Console.EXE -> DLL -> WS1 aufrufen -> DLL -> WS2 aufrufen

Ich hatte sowohl die Konfigurationen des Servicemodells von WS1 als auch von WS2 in der Console.EXE.config wie empfohlen. - hat das Problem nicht gelöst.

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

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

Lösung: Ändern Sie die Konfiguration des äußeren Projekts genauso wie die wcf-Konfiguration der Klassenbibliothek.

Hat für mich gearbeitet

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

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

Die Lösung für mich bestand darin, den Endpunktnamen aus dem Attribut Endpunktname in der Client-Datei web.config zu entfernen, damit der Proxy ihn verwenden konnte

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

Es dauerte nur den ganzen Tag, um zu trainieren. Auch der Vertragsname war falsch, als dieser Fix vorhanden war, obwohl er falsch war, als der anfängliche Fehler auftrat. Doppelte und dreifache Überprüfung auf Vertragsnamen Zeichenfolgen Menschen! attrib: Ian

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

In meiner web.configDatei war Folgendes definiert:

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

Ich habe bereits basicHttpsBinding für eine Referenz verwendet, aber dann habe ich eine neue Referenz hinzugefügt, für die basicHttpBinding (no s) erforderlich ist. Alles was ich tun musste, war das protocolMappingwie folgt zu meinem hinzuzufügen :

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

Wie LR richtig hervorhebt, muss dies an den richtigen Stellen definiert werden. Für mich bedeutete dies eine in der app.config meines Unit-Test-Projekts sowie eine in der web.config des Hauptserviceprojekts.

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

dh

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

funktioniert, aber

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

gibt den Fehler "Standardendpunktelement konnte nicht gefunden werden, das auf den Vertrag verweist" aus.

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

Wenn Sie eine Servicereferenz hinzufügen

Achten Sie auf den Namespace, den Sie eingeben:

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>

Ich habe den gleichen Fehler erhalten und viele Dinge ausprobiert, aber nicht funktioniert. Als ich bemerkte, dass mein "Vertrag" nicht bei allen Projekten gleich war, habe ich den Vertrag so geändert, wie er für alle Projekte innerhalb der Lösung gleich war und dann funktionierte er. 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 mich für beide geändert als:

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

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