Content Type text/xml; charset=utf-8 was not supported by service

I have a problem with a WCF service. I have a console application and I need to consume the service without using app.config, so I had to set the endpoint, etc. by code. I do have a service reference to the svc, but I can't use the app.config. Here's my code:

BasicHttpBinding binding = new BasicHttpBinding();


EndpointAddress address = new EndpointAddress("http://localhost:8731/WcfServicio/MiServicio");


MiServicioClient svc = new MiServicioClient(binding, address);
object ob = svc.PaisesObtener();

At the last line when I do svc.PaisesObtener() I get the error:

Content Type text/xml; charset=utf-8 was not supported by service
http://localhost:8731/WcfServicio/MiServicio.  The client and service bindings may be mismatched.
160490 次浏览
小开

First Google hit says:

this is usually a mismatch in the client/server bindings, where the message version in the service uses SOAP 1.2 (which expects application/soap+xml) and the version in the client uses SOAP 1.1 (which sends text/xml). WSHttpBinding uses SOAP 1.2, BasicHttpBinding uses SOAP 1.1.

It usually seems to be a wsHttpBinding on one side and a basicHttpBinding on the other.

小开

Do not forget check the bindings-related code too. So if you wrote:

BasicHttpBinding binding = new BasicHttpBinding();

Be sure that all your app.config files contains

<endpoint address="..."
binding="basicHttpBinding" ...

not the

<endpoint address="..."
binding="wsHttpBinding" ...

or so.

小开

I've seen this behavior today when the 

   <service name="A.B.C.D" behaviorConfiguration="returnFaults">
<endpoint contract="A.B.C.ID" binding="basicHttpBinding" address=""/>
</service>

was missing from the web.config. The service.svc file was there and got served. It took a while to realize that the problem was not in the binding configuration it self...

小开

I saw this problem today when trying to create a WCF service proxy, both using VS2010 and svcutil.

Everything I'm doing is with basicHttpBinding (so no issue with wsHttpBinding).

For the first time in my recollection MSDN actually provided me with the solution, at the following link How to: Publish Metadata for a Service Using a Configuration File. The line I needed to change was inside the behavior element inside the MEX service behavior element inside my service app.config file. I changed it from

<serviceMetadata httpGetEnabled="true"/>

to

<serviceMetadata httpGetEnabled="true" policyVersion="Policy15"/>

and like magic the error went away and I was able to create the service proxy. Note that there is a corresponding MSDN entry for using code instead of a config file: How to: Publish Metadata for a Service Using Code.

(Of course, Policy15 - how could I possibly have overlooked that???)

One more "gotcha": my service needs to expose 3 different endpoints, each supporting a different contract. For each proxy that I needed to build, I had to comment out the other 2 endpoints, otherwise svcutil would complain that it could not resolve the base URL address.

小开

I was also facing the same problem recently. after struggling a couple of hours,finally a solution came out by addition to 

Factory="System.ServiceModel.Activation.WebServiceHostFactory"
to your SVC markup file. e.g.
ServiceHost Language="C#" Debug="true" Service="QuiznetOnline.Web.UI.WebServices.LogService"
Factory="System.ServiceModel.Activation.WebServiceHostFactory"

and now you can compile & run your application successfully.

小开

I was facing the similar issue when using the Channel Factory. it was actually due to wrong Contract specified in the endpoint.

小开

For anyone who lands here by searching:

content type 'application/json; charset=utf-8' was not the expected type 'text/xml; charset=utf-8

or some subset of that error:

A similar error was caused in my case by building and running a service without proper attributes. I got this error message when I tried to update the service reference in my client application. It was resolved when I correctly applied [DataContract] and [DataMember] attributes to my custom classes.

This would most likely be applicable if your service was set up and working and then it broke after you edited it.

小开

Again, I stress that namespace, svc name and contract must be correctly specified in web.config file:

 <service name="NAMESPACE.SvcFileName">
<endpoint contract="NAMESPACE.IContractName" />
</service>

Example:

<service name="MyNameSpace.FileService">
<endpoint contract="MyNameSpace.IFileService" />
</service>

(Unrelevant tags ommited in these samples)

小开

In my case, I had to specify messageEncoding to Mtom in app.config of the client application like that:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />
</startup>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="IntegrationServiceSoap" messageEncoding="Mtom"/>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:29495/IntegrationService.asmx"
binding="basicHttpBinding" bindingConfiguration="IntegrationServiceSoap"
contract="IntegrationService.IntegrationServiceSoap" name="IntegrationServiceSoap" />
</client>
</system.serviceModel>
</configuration>

Both my client and server use basicHttpBinding. I hope this helps the others :)

小开

I had this error and all the configurations mentioned above were correct however I was still getting "The client and service bindings may be mismatched" error.

What resolved my error, was matching the messageEncoding attribute values in the following node of service and client config files. They were different in mine, service was Text and client Mtom. Changing service to Mtom to match client's, resolved the issue.

<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IMySevice" ... messageEncoding="Mtom">
...
</binding>
</basicHttpBinding>
</bindings>
</system.serviceModel>
</configuration>

提交答案