Friday, July 24, 2009

Web Services - Now, that's an adventure

Recently we got this wonderful exception at work:

WebHost failed to process a request.

Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/4110503

Exception: System.ServiceModel.ServiceActivationException: The service '{ServiceName}.svc' cannot be activated due to an exception during compilation. The exception message is: Operation '{MethodName}' of contract '{InterfaceName}' specifies multiple request body parameters to be serialized without any wrapper elements. At most one body parameter can be serialized without wrapper elements. Either remove the extra body parameters or set the BodyStyle property on the WebGetAttribute/WebInvokeAttribute to Wrapped.. ---> System.InvalidOperationException: Operation '{MethodName}' of contract '{InterfaceName}' specifies multiple request body parameters to be serialized without any wrapper elements. At most one body parameter can be serialized without wrapper elements. Either remove the extra body parameters or set the BodyStyle property on the WebGetAttribute/WebInvokeAttribute to Wrapped.

I don't usually blog about exceptions because I cause so many of them! I'd never have time to make more if I wrote about each one! Well, actually, usually someone else has already thoroughly blogged about it. In this case, I did not stumble upon a blog for this exception. It was nearly as exciting as the birth of another child. So, I'll name it... "Targort".

So, where did Targort come from and how was Targort corrected?

I cannot answer that without putting a little adventure into the story first. So, we had a huge demo on the horizon and we'd been testing and tweaking for weeks. The development machines were smoking! The build server was sweating and gasping for air and the demo server looked to be coming online nicely. Then with 48 hours to go before the demo we found this one service was not running on the demo server. Of course, "everything was the same on the 2 boxes." So, it couldn't be the boxes. Finally, my boss, Roberto the Wise, was able to conclusively eliminate the boxes. We had other interfaces within the same service that would work, everything else checked out and all the evidence pointed to the code (AKA me, the meek).

Time was running short but we really suspected it was something in the code even though the code in the .svc.cs file was pretty vanilla because it was essentially just a facade in front of the real logic in the system.

Finally, my colleague, Marco the Magnificent, looked at the .svc file. You know, it is one of those files that you never look at because it has "nothing in it." Well, there lay the treasure we were searching for. The file, which had never been altered since it was created and had worked/compiled on numerous other servers, had quite a bit of information in it that didn't seem to correspond to anything we were doing:

This is what it looked like:

ServiceHost Language="C#" Factory="System.Data.Services.DataServiceHostFactory, System.Data.Services, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Service="SharedServicesService.DocManInfo.DocManInfoService"

True, our service was in the namespace "SharedServicesService.DocManInfo.DocManInfoService" but what did "System.Data.Services.DataServiceHostFactory, System.Data.Services, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" have to do with anything?

Once we changed the file to this:

ServiceHost Language="C#" Debug="true" Service="SharedServicesService.DocManInfo.DocManInfoService" CodeBehind="DocManInfoService.svc.cs"

(I was forced to omit the starting and ending characters in these files due to the limitation/restriction within blogger on certain character combinations)


Everything came together perfectly and we had 11 minutes left before the demo!


The server wasn't the only thing sweating during this adventure. I hope you enjoyed it as much as we did. Or at least, I hope this will solve your problem if you ever run into Targort the Terrible in the jungle.


Just a good piece of troubleshooting advice on web services, always make sure the WSDL file can be viewed in the browser. If the WSDL won't work, that narrows things down to a compile time issue.

No comments: