Exploring all things .NET and beyond...

Fixing the WCF 'The remote server returned an error: (415) Unsupported Media Type.HTTP GET' Error

Recently I was building a typical WCF service hosted in IIS on Windows7 using VS.NET 2010 (I have done this several times). Every time I either tried to start the service within VS.NET locally, or actually consume the installed IIS instance on my local machine I would get the following error:

"Error: Cannot obtain Metadata from http://localhost:3509/MyNetworkingService.svc The remote server returned an error: (415) Unsupported Media Type.HTTP GET Error"

I thought I had tried everything with the configuration; had all my "i" 's dotted and my "t" 's crossed. Plus the (415) Unsupported Media Type portion of the message was really throwing me off the proper path to fix the issue. The problem and the fix? A spelling mistake in the name of the service within the .config file. Fixing it was as easy as copying the properly assigned service name from the .svc Markup and into the .config file.

I had the word 'Networking' in my service name, and I spelled it 'Netwoking'. They were so close visually that it didn’t present itself immediately. As many services as I have created and still made a rookie mistake. A nice "Your service name and configuration service name don't match" message would have been nicer than a (415) Unsupported Media Type error, but no big deal it was my mistake.

The real lesson learned for the future - just be safe and copy the name used in the markup of the .svc file (you can get to this by right-clicking the .svc file in Solution Explorer and selecting "View Markup") and paste it into the .config. Below is a working template for a barebones WCF service hosted in IIS using "basicHttpBinding":


<system.serviceModel>
<services>
<service name="MyNetworkingService.NetworkingService"
behaviorConfiguration="ServiceBehavior">
<endpoint address=""
binding="basicHttpBinding"
contract="MyNetworkingService.INetworkingService" />

<endpoint address="mex"
binding="mexHttpBinding"
contract="IMetadataExchange" />
<!--When hosting a WCF service in IIS, you don't need to specify a base address nor an endpoint,
because the Endpoint will simply be the Virtual Path that your service points to.-->

</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<!-- 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 faults for debugging purposes,
set the value below to true. Set to false before deployment to
avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>

10 comments:

Anonymous said...

Allen, your post saved my butt today! Thanks.

Madman said...

I had the same issue and indeed it was stupid misprint. Thanks :)

Anonymous said...

THANK YOU!!!

Anonymous said...

I have solved my problem same like shown in this blog.....
Thank you

Anonymous said...

Thanks!

Anonymous said...

5 day finding how resolve my problem , and you save my job jajajaja thanks man

Anonymous said...

Allen, you made my day! Thanks for that!

Anonymous said...

Oujeeee......thanks a lot man, it helps me :)

Anonymous said...

Brilliant. Didn't realise that "MyNetworkingService" is actually referring to my namespace.

Sotiris Leventis said...

I came across this question when troubleshooting this error, so I thought I would help the next person who might come through here. I ran into this error when at some point I had to take over an existing solution which was utilizing WSE and MTOM encoding. It was a windows client calling a web service.

To the point, the client was calling the web service where it would throw that error.
Something that contributed to resolving that error for me was to check the web service proxy class that apparently is generated by default to inherit from System.Web.Services.Protocols.SoapHttpClientProtocol.
Essentially that meant that it didn't actually use WSE3.

Anyhow I manually edited the proxy and changed it to inherit from Microsoft.Web.Services3.WebServicesClientProtocol.

BTW, to see the generated proxy class in VS click on the web reference and then click the 'Show All Files' toolbar button. The reference.cs is da place of joy!

Hope it helps.

Post a Comment