Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

“Add Service Reference”: When WCF Metadata Goes Wrong

DZone's Guide to

“Add Service Reference”: When WCF Metadata Goes Wrong

· ·
Free Resource

I was helping a student debug a WCF service the other day and stumbled upon a very annoying problem. Visual Studio refused to add a service reference to his service, no matter what we tried. After spending a few minutes copy-pasting configuration snippets from Stack Overflow, I decided to proceed more methodically and see what we’re doing wrong.

Here’s the error we were getting, courtesy of the Visual Studio “Add Service Reference” dialog:

Error Adding Service Reference

At first, I was under the impression that something is wrong with the metadata endpoint itself. Perhaps I used the wrong spelling of IMetadataExchange? Or maybe I don’t have permissions to listen on port 9091? I tried toying around with moving to a net.tcp metadata endpoint, still to no avail.

Try taking a look at the code yourself before you go on. The example is entirely self-sufficient and requires less than 50 lines of code, including console printouts.

Exasperated, I turned to the web browser and hit the metadata URL. Here’s what the service said:

The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.

An internal error in the metadata publishing process? Something is rotten, etc. — time to turn on the IncludeExceptionDetailInFaults property on the ServiceDebugBehavior. That immediately pointed out the culprit, in so many words:

The service encountered an error.

An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.InvalidOperationException: An exception was thrown in a call to a WSDL export extension: System.ServiceModel.Description.DataContractSerializerOperationBehavior
 contract: http://tempuri.org/:IChatService ----> System.InvalidOperationException: The WcfMetadataIssue.IChatClient.Message operation references a message element [http://tempuri.org/:Message] that has already been exported from the WcfMetadataIssue.IChatService.Message operation. You can change the name of one of the operations by changing the method name or using the Name property of OperationContractAttribute. Alternatively, you can control the element name in greater detail using the MessageContract programming model.
   at System.ServiceModel.Description.MessageContractExporter.AddElementToSchema(XmlSchemaElement element, String elementNs, XmlSchemaSet schemaSet)
   at System.ServiceModel.Description.MessageContractExporter.ExportWrappedPart(Message message, String elementName, String elementNs, XmlSchemaSet schemaSet, Boolean skipSchemaExport)
...snipped for brevity...

There’s an example of a great exception message! Turns out we had a callback contract that declared a method with the same name as an existing method on the service contract. Because we were using the default namespace and didn’t customize the operation names, they couldn’t be exported to WSDL. We proceeded to change the operation name on the callback contract, and all was well again in WCF-land.

I am posting short links and updates on Twitter as well as on this blog. You can follow me: @goldshtn

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}