Dies kann daran liegen, dass die Service-Endpunktbindung das HTTP-Protokoll nicht verwendet

Auf meinem lokalen Computer läuft ein WCF-Dienst einwandfrei. Ich habe es auf die Server gestellt und erhalte die folgende Fehlermeldung:

Beim Empfang der HTTP-Antwort auf http: //xx.xx.x.xx: 8200 / Services / WCFClient.svc ist ein Fehler aufgetreten . Dies kann daran liegen, dass die Service-Endpunktbindung das HTTP-Protokoll nicht verwendet. Dies kann auch daran liegen, dass ein HTTP-Anforderungskontext vom Server abgebrochen wird (möglicherweise aufgrund des Herunterfahrens des Dienstes). Weitere Informationen finden Sie in den Serverprotokollen.]

Ich habe den Dienst in der URL aufgerufen und er funktioniert ordnungsgemäß. Alles, was ich für die Funktion tue, ist, eine Zeichenfolge an einen Bildnamen zurückzugeben, sodass die übergebenen Daten nicht viel sind. Ich habe das Protokoll verfolgt und es gibt mir die gleichen Informationen. Hier ist meine Client-Konfiguration:

<binding name="basicHttpBinding_IWCFClient" closeTimeout="00:01:00"
         openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
         bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
         maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647"
         messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
         allowCookies="false">
    <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" 
                  maxArrayLength="2147483647" maxBytesPerRead="2147483647" 
                  maxNameTableCharCount="2147483647" />
    <security mode="None">
        <transport clientCredentialType="None" proxyCredentialType="None" realm="" />
        <message clientCredentialType="UserName" algorithmSuite="Default" />
    </security>
</binding>
<endpoint name="basicHttpBinding_IWCFClient" 
    address="http://localhost:4295/Services/WCFClient.svc"
    binding="basicHttpBinding" 
    bindingConfiguration="basicHttpBinding_IWCFClient" 
    behaviorConfiguration="WCFGraphicManagementTool.Services.ClientBehavior"
    contract="WCFClient.IWCFClient" />

Hier ist meine Serverkonfiguration:

<service behaviorConfiguration="WCFGraphicManagementTool.Services.WCFClientBehavior"
    name="WCFGraphicManagementTool.Services.WCFClient">
   <endpoint name="basicHttpBinding_IWCFClient"
       address="" 
       binding="basicHttpBinding" 
       contract="WCFGraphicManagementTool.Contracts.IWCFClient" />
   <endpoint 
       address="mex" 
       binding="mexHttpBinding" 
       contract="IMetadataExchange" />
</service>
<behavior name="WCFGraphicManagementTool.Services.WCFClientBehavior">
   <dataContractSerializer maxItemsInObjectGraph="2147483647" />
   <serviceThrottling maxConcurrentCalls="120" maxConcurrentSessions="120"
                      maxConcurrentInstances="120" />
   <serviceMetadata httpGetEnabled="true" />
   <serviceDebug includeExceptionDetailInFaults="true" />
</behavior>

Wäre es eine Einstellung auf dem Server, da sie auf meinem lokalen Computer funktioniert?

Ich denke, es gibt ein Serialisierungsproblem. Sie können einen genauen Fehler finden, indem Sie den folgenden Code in der Dienstkonfiguration im <configuration>Abschnitt hinzufügen .

Nachdem die Konfigurationsaktualisierungsdatei "App_tracelog.svclog"erstellt wurde, müssen Sie nur die .svclogDatei öffnen und die rote Farblinie auf der linken Seite finden. Dies ist ein Fehler. Weitere Informationen finden Sie in der Beschreibung.

Ich hoffe, dies wird helfen, Ihren Fehler zu finden.

<system.diagnostics>
    <sources>
      <source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">
        <listeners>
          <add name="ServiceModelTraceListener" />
        </listeners>
      </source>
      <source name="System.ServiceModel" switchValue="Verbose,ActivityTracing">
        <listeners>
          <add name="ServiceModelTraceListener" />
        </listeners>
      </source>
      <source name="System.Runtime.Serialization" switchValue="Verbose,ActivityTracing">
        <listeners>
          <add name="ServiceModelTraceListener" />
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add initializeData="App_tracelog.svclog" type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ServiceModelTraceListener" traceOutputOptions="Timestamp" />
    </sharedListeners>
  </system.diagnostics>

Ich hatte das Problem "Dies könnte daran liegen, dass die Dienstendpunktbindung nicht das HTTP-Protokoll verwendet" und der WCF-Dienst wurde heruntergefahren (auf einem Entwicklungscomputer).

Ich fand heraus: In meinem Fall lag das Problem an Enums,

Ich habe das gelöst

    [DataContract]
    [Flags]
    public enum Fruits
    {
        [EnumMember]
        APPLE = 1,
        [EnumMember]
        BALL = 2,
        [EnumMember]
        ORANGE = 3 

    }

Ich musste meine Enums mit DataContract, Flags und allen Enum-Mitgliedern mit EnumMember-Attributen dekorieren.

Ich habe dies gelöst, nachdem ich mir diese MSDN-Referenz angesehen habe :

Ich hatte den gleichen Fehler und das Problem war die Serialisierung. Ich habe es geschafft, das eigentliche Problem mit Service Trace Viewer http://msdn.microsoft.com/en-us/library/ms732023.aspx zu finden und es einfach zu lösen. Vielleicht hilft das jemandem.

In meinem Fall wurde der Fehler generiert, weil einer meiner komplexen Typen eine Eigenschaft ohne festgelegte Methode hatte.

Der Serializer hat aufgrund dieser Tatsache eine Ausnahme ausgelöst. Interne Set-Methoden hinzugefügt und alles hat gut funktioniert.

Der beste Weg, um herauszufinden, warum dies geschieht (meiner Meinung nach), ist die Aktivierung der Ablaufverfolgungsprotokollierung.

Dies habe ich erreicht, indem ich meinem Abschnitt den folgenden Abschnitt hinzugefügt habe web.config:

<system.diagnostics>
  <sources>
    <source name="System.ServiceModel.MessageLogging" switchValue="Warning,ActivityTracing">
      <listeners>
        <add name="traceListener"
              type="System.Diagnostics.XmlWriterTraceListener"
              initializeData= "c:\log\Traces.svclog" />
        <add type="System.Diagnostics.DefaultTraceListener" name="Default" />
      </listeners>
    </source>
    <source propagateActivity="true" name="System.ServiceModel" switchValue="Verbose,ActivityTracing">
      <listeners>
        <add name="traceListener"
              type="System.Diagnostics.XmlWriterTraceListener"
              initializeData= "c:\log\Traces.svclog" />
        <add type="System.Diagnostics.DefaultTraceListener" name="Default" />
      </listeners>
    </source>
  </sources>
  <trace autoflush="true" />
</system.diagnostics>

Nach dem Festlegen habe ich meinen Client ausgeführt, eine Ausnahme erhalten und die Datei 'Traces.svclog' überprüft. Von dort musste ich nur noch die Ausnahme finden.

Die Lösung mit DataContract, Flags for Enums, sieht etwas hässlich aus. In meinem Fall wurde das Problem durch Hinzufügen von "NotSet = 0" in enum gelöst:

public enum Fruits
{
  UNKNOWN = 0,
  APPLE = 1,
  BALL = 2,
  ORANGE = 3 
}

Ich hatte das gleiche Problem und wurde mit dem folgenden Code gelöst. (wenn ein TLS-Konnektivitätsproblem vorliegt)

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;

Bitte fügen Sie diese Zeile ein, bevor Sie den Client-Kanal öffnen.

Ich habe das Problem herausgefunden. Es war ein falscher Pfad zu meiner Konfigurationsdatei. Die Fehler für WCF sind manchmal so hilfreich.

Um dies zu beheben, mussten wir die AppPool-Identität in ein Administratorkonto ändern .

Ich habe diesen Fehler gesehen, der durch einen Zirkelverweis im Objektdiagramm verursacht wurde. Das Einfügen eines Zeigers auf das übergeordnete Objekt eines untergeordneten Objekts führt dazu, dass der Serializer eine Schleife ausführt und letztendlich die maximale Nachrichtengröße überschreitet.

Dieser Fehler kann auf eine Vertragsinkongruenz zurückzuführen sein. Betrachten Sie die dreischichtige Anwendung unten ...

UI-Ebene
|
Prozessschicht
|
Datenzugriffsschicht
-> Vertrag zwischen Prozess- und UI-Schicht hat dieselbe Aufzählung wie fehlt (Onhold = 3). Enum: Start = 1, Stop = 2. -> Vertrag zwischen Datenzugriff und Prozessschicht hat Enum Enum: Start = 1, Stop = 2, Onhold = 3.

In diesem Fall erhalten wir den gleichen Fehler in der Antwort der Prozessschicht.

Der gleiche Fehler tritt bei anderen Vertragsinkongruenzen in mehrschichtigen Anwendungen auf.

Ich hatte dieses Problem, weil ich meinen WCF-Dienst so konfiguriert habe, dass er eine System.Data.DataTable zurückgibt.

Es hat in meiner Test-HTML-Seite gut funktioniert, ist aber in die Luft gesprengt, als ich dies in meine Windows Form-Anwendung eingefügt habe.

Ich musste die Signatur des Betriebsvertrags des Dienstes von DataTable in DataSet ändern und die Daten entsprechend zurückgeben.

Wenn Sie dieses Problem haben, möchten Sie möglicherweise einen zusätzlichen Betriebsvertrag zu Ihrem Service hinzufügen, damit Sie sich keine Gedanken über das Brechen von Code machen müssen, der auf vorhandenen Services basiert.

Dies kann viele Gründe haben; Im Folgenden sind einige davon aufgeführt:

1. Wenn Sie komplexe Datenvertragsobjekte verwenden (dh ein benutzerdefiniertes Objekt mit mehr untergeordneten benutzerdefinierten Objekten), stellen Sie sicher, dass alle benutzerdefinierten Objekte mit den Attributen DataContract und DataMember dekoriert sind

2. Wenn Ihre Datenvertragsobjekte Vererbung verwenden, stellen Sie sicher, dass alle Basisklassen über die Attribute DataContract und DataMember verfügen. Außerdem müssen die Basisklassen die abgeleiteten Klassen mit dem Attribut [KnownType (typeof (BaseClassType))] angeben ( weitere Informationen hierzu finden Sie hier ).

3. Stellen Sie sicher, dass alle Eigenschaften Ihres Datenvertragsobjekts sowohl get- als auch set-Eigenschaften haben.

Mein Problem war, dass zu viele Elemente zwischen Client und Server übertragen wurden. Ich musste diese Einstellungen im Verhalten auf beiden Seiten ändern.

<dataContractSerializer maxItemsInObjectGraph="2147483646"/>

Dies ist möglicherweise nicht relevant für Ihr spezifisches Problem, aber die von Ihnen erwähnte Fehlermeldung hat viele Ursachen. Eine davon verwendet einen Rückgabetyp für einen [OperationContract], der entweder abstrakt, schnittstellen oder dem WCF-Clientcode nicht bekannt ist.

Überprüfen Sie den Beitrag (und die Lösung) unten

https://stackoverflow.com/a/5310951/74138

Ich denke, der beste Weg, dies zu lösen, besteht darin, den Fehlerhinweisen zu folgen und daher nach Serverprotokollen zu suchen. Um Protokolle zu aktivieren, habe ich hinzugefügt

 <system.diagnostics>
    <sources>
      <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
        <listeners>
          <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\TracesServ_ce.svclog" />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>

Gehen Sie dann zu c: \ logs \ TracesServ_ce.svclog und öffnen Sie es mit dem Microsoft Service Trace Viewer. Und sehen Sie, was das Problem wirklich ist.

Weitere Informationen zu diesem Problem finden Sie auch unter: Eine vorhandene Verbindung wurde vom Remote-Host - WCF - zwangsweise geschlossen

Mein Problem war schließlich, dass meine Datenübertragungsobjekte zu komplex waren. Beginnen Sie mit einfachen Eigenschaften wie public long Id { get; set; }und sobald Sie diese zum Laufen gebracht haben, fügen Sie nach Bedarf zusätzliche Dinge hinzu.

Ich hatte ein paar Tage damit zu kämpfen und versuchte jede Antwort aus diesem und vielen anderen Beiträgen und teilte meine Lösung, weil die Symptome gleich waren, aber das Problem anders war.

Das Problem war, dass der App-Pool mit einem Speicherlimit konfiguriert wurde und erst nach einem variablen Zeitraum wiederverwendet wird.

Hoffe das hilft jemand anderem!
Schöne Grüße,

Mein Problem war, dass der Rückgabetyp meines Dienstes Zeichenfolge war. Aber ich habe eine Zeichenfolge vom Typ xml zurückgegeben:

<reponse><state>1</state><message>Operation was successfull</message</response>

so wurde Fehler geworfen.

in meinem Fall

Mein Service hat Funktion zu download Files

und dieser Fehler wurde nur beim Versuch des Herunterladens angezeigt Big Files

Also fand ich diese Antwort auf Erhöhen maxRequestLengthauf den benötigten Wert inweb.config

Ich weiß, das ist komisch, aber das Problem ist gelöst

Wenn Sie keine Upload- oder Download-Vorgänge ausführen, hilft Ihnen diese Antwort möglicherweise nicht weiter

Für mich sind die Lösungen dieses Fehlers sehr seltsam. Es war das Problem der Portadresse von EndpointAddress . In Visual Studio müssen die Portadresse Ihrer Datei (z. B. Service1.svc) und die Portadresse Ihres wcf-Projekts dieselbe sein, die Sie in EndpointAddress angegeben haben . Lassen Sie mich Ihnen diese Lösung im Detail beschreiben.

Es gibt zwei Schritte, um die Portadressen zu überprüfen.

1. In der rechten WCF - Projekt Service - Datei klicken (zB Service1.svc) -> als wählen Sie im Browser jetzt in Ihrem Browser haben Sie URL wie http: // localhost: 61122 / Service1.svc so beachten Sie jetzt Ihre Port - Adresse unten als a 61122

2. Klicken Sie mit der rechten Maustaste auf Ihr wcf-Projekt -> wählen Sie dann Eigenschaften -> gehen Sie zur Registerkarte Web -> Jetzt im Abschnitt Server -> wählen Sie Visual Studio Development Server verwenden -> wählen Sie Spezifischer Port aus und geben Sie die Portadresse an, die wir zuvor von unserem Service1 gefunden haben. SVC-Dienst. Das ist (61122) .

Früher habe ich eine andere Portadresse. Nachdem ich die Portadresse richtig angegeben habe, die ich in EndpointAddress angegeben habe , , wurde mein Problem behoben.

Ich hoffe, dies könnte Ihr Problem lösen.

Hatte auch dieses Problem und es war darauf zurückzuführen, dass ich vergessen hatte, mein Modell mit DataContract- und DataMember-Attributen zu dekorieren