Inhaltstypanwendung/Seife + xml; charset = utf-8 wurde vom Dienst nicht unterstützt

Ich stoße auf ein Namensproblem. Der Servicename muss genau der Name Ihrer Implementierung sein. Bei Nichtübereinstimmung verwendet es standardmäßig basicHttpBinding, was zum Inhaltstyp text/xml führt. 

Der Name Ihrer Klasse befindet sich an zwei Stellen - SVC-Markup und CS-Datei.

Überprüfen Sie auch den Endpunktvertrag - wieder den genauen Namen Ihrer Schnittstelle, mehr nicht. Ich habe den Namen der Assembly hinzugefügt, der einfach nicht da sein kann.

<service name="MyNamespace.MyService">
    <endpoint address="" binding="wsHttpBinding" contract="MyNamespace.IMyService" />
    <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
  </service>

Hier ist das Beispiel einer web.config, die das Problem für mich löst. Achten Sie auf die <binding name = "TransportSecurity" messageEncoding = "Text" textEncoding = "utf-8">

Ich hatte das gleiche Problem und bekam es durch das "Binden" des Dienstes mit dem Dienstverhalten so:

Gib dem Verhalten einen Namen

<serviceBehaviors>
        <behavior name="YourBehaviourNameHere">

Und einen Hinweis auf Ihr Verhalten in Ihrem Service

<services>
  <service name="WCFTradeLibrary.TradeService" behaviorConfiguration="YourBehaviourNameHere">

Das Ganze wäre:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

  <system.web>
    <compilation debug="true" />
  </system.web>
  <!-- When deploying the service library project, the content of the config file must be added to the Host's 
  app.config file. System.Configuration does not support config files for libraries. -->
  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="basicHttp" allowCookies="true"
                 maxReceivedMessageSize="20000000"
                 maxBufferSize="20000000"
                 maxBufferPoolSize="20000000">
          <readerQuotas maxDepth="32"
               maxArrayLength="200000000"
               maxStringContentLength="200000000"/>
        </binding>
      </basicHttpBinding>
    </bindings>
    <services>
     <service name="WCFTradeLibrary.TradeService" behaviourConfiguration="YourBehaviourNameHere">
        <endpoint address="" binding="basicHttpBinding" bindingConfiguration="basicHttp" contract="WCFTradeLibrary.ITradeService">          
         </endpoint>
     </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="YourBehaviourNameHere">
          <!-- To avoid disclosing metadata information, 
          set the value below to false and remove the metadata endpoint above before deployment -->
          <serviceMetadata httpGetEnabled="true"/>
          <!-- To receive exception details in faul`enter code here`ts for debugging purposes, 
          set the value below to true.  Set to false before deployment 
          to avoid disclosing exception info`enter code here`rmation -->
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

</configuration>

In meinem Fall hatte eine der Klassen keinen Standardkonstruktor - und Klassen ohne Standardkonstruktor können nicht serialisiert werden.

Wie andere bereits sagten, geschieht dies aufgrund von Unstimmigkeiten bei Service-Clients.

Ich stieß auf das gleiche Problem, als beim Debuggen festgestellt wurde, dass die Bindung nicht übereinstimmt. Anstelle von WSHTTPBinding bezog ich mich auf BasicHttpBinding. In meinem Fall beziehe ich mich sowohl auf BasicHttp als auch auf WsHttp. Ich habe die Bindung dynamisch anhand der Referenz zugewiesen. Überprüfen Sie also Ihren Service-Konstruktor.

Überprüfen Sie einmal Ihren Service Constructor . Überprüfen Sie das folgende Bild

Für mich war es sehr schwierig, das Problem aufgrund einer großen Anzahl von Methoden und Klassen zu identifizieren.

Was ich getan habe, ist einige Methoden aus der WebService-Schnittstelle kommentiert (kommentiert) und zu versuchen, und dann eine Reihe weiterer Methoden zu kommentieren und zu versuchen. Ich tat dies so lange, bis ich die Methode gefunden habe, die das Problem verursacht.

In meinem Fall wurde ein komplexes Objekt verwendet, das nicht serialisiert werden kann.

Viel Glück!

Mein Fall hatte eine andere Lösung. Der Client verwendete basichttpsbinding [1] und der Dienst verwendete wshttpbinding. 

Ich habe das Problem durch Ändern der Serverbindung in basichttpsbinding ..__ gelöst. Außerdem musste ich das Zielframework auf 4.5 setzen, indem ich Folgendes hinzufügte:

  <system.web>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5"/>
  </system.web>

[1] Die Kommunikation war über https.

Dieser Fehler kann auftreten, wenn WCF-Client versucht, seine Nachricht mit MTOM extension (MIME type application/soap+xml zu senden, um SOAP XML in MTOM zu übertragen, der Dienst kann jedoch nur normale SOAP -Nachrichten verstehen (er enthält keine MIME-Teile, nur Text/XML-Typ) HTTP-Anfrage).

Stellen Sie sicher, dass Sie Ihren Client-Code gegen die korrekte WSDL generiert haben. 

Um MTOM auf dem Server zu verwenden, ändern Sie Ihre Konfigurationsdatei und fügen Sie messageEncoding attribute hinzu:

<binding name="basicHttp" allowCookies="true"
             maxReceivedMessageSize="20000000"
             maxBufferSize="20000000"
             maxBufferPoolSize="20000000"
             messageEncoding="Mtom" >

Bei der Verwendung von WebServiceTemplate spring ws [err] org.springframework.ws.client.WebServiceTransportException wurde derselbe Fehler angezeigt: Die Nachricht kann nicht verarbeitet werden, da der Inhaltstyp 'text/xml; charset = utf-8 'war nicht der erwartete Typ' application/soap + xml; Zeichensatz = utf-8 '. [415] [Fehler] unter org.springframework.ws.client.core.WebServiceTemplate.handleError (WebServiceTemplate.Java:665). Die WSDL, die ich verwendete, hat soap1.2-Protokoll und standardmäßig ist das Protokoll soap1.1. Als ich das Protokoll unter Verwendung des folgenden Codes änderte, funktionierte es

 MessageFactory msgFactory = MessageFactory.newInstance(javax.xml.soap.SOAPConstants.SOAP_1_2_PROTOCOL);
     SaajSoapMessageFactory saajSoapMessageFactory = new SaajSoapMessageFactory(msgFactory);
     saajSoapMessageFactory.setSoapVersion(SoapVersion.SOAP_12);
     getWebServiceTemplate().setMessageFactory(saajSoapMessageFactory);

Ich habe die gleiche Fehlermeldung erhalten. Ich habe es geschafft, es zu beheben:

In meinem Fall bestand der Fehler darin, dass ich die Attribute [datacontract] und [datamember] in der übergeordneten Klasse meiner zurückgegebenen Klasse verpasst habe. Die Fehlermeldung war irreführend.

[OperationContract]
List<MyClass> GetData();

[DataContract]
public class MyClass : MyParentClass
{       
    [DataMember]
    public string SomeString { get; set; }      
}

// Missing DataContract
public class MyParentClass
{
    // Missing DataMember
    public int SomeNumber { get; set; }

}

Mein Problem war unsere eigene Collection-Klasse, die mit [DataContract] gekennzeichnet wurde. Aus meiner Sicht war dies ein sauberer Ansatz und es funktionierte gut mit XmlSerializer, aber für den WCF-Endpunkt brach er und wir mussten ihn entfernen. XmlSerializer funktioniert auch ohne.

Funktioniert nicht

[DataContract]
public class AttributeCollection : List<KeyValuePairSerializable<string, string>>

Arbeiten

public class AttributeCollection : List<KeyValuePairSerializable<string, string>>

Ich hatte auch den gleichen Fehler in den Ablaufprotokollen. Meine neu erstellte Funktion in API warf den gleichen Fehler, aber zu meiner Überraschung funktionierten die alten Funktionen gut. Das Problem war - Meine Vertragsdatenmitglieder hatten wenige Variablen vom Typ Objekt. soap-xml konnte nicht gut damit umgehen, jedoch sehe ich, dass das Array der Objekttypen (object []) ohne Probleme übergeben wurde. Nur ein einfacher Objekttyp wurde nicht von Seife analysiert. Dies könnte ein weiterer Grund sein, warum die Dienste den obigen Fehler auslösen. 

In meinem Fall wurde derselbe Fehler durch Vermissen verursacht 

[DataContract]
...
[DataMember] 

attribute im zurückgegebenen Datentyp.

Prüfen Sie das und versuchen Sie, diese hinzuzufügen, und prüfen Sie, ob es hilfreich ist.