Friday, March 5, 2010

Add Service Reference duplicates properties on Faults

Spent the last few days fighting with this, finally found what seems to be a workaround so I thought I'd share hoping that it can be of some use to some other poor devil who's stuck.

Dealing with WebSphere generated web services, the curious occurrence of duplicate properties on Faults (on different partial classes) was encountered when generating proxies through add service reference on Visual Studio 2008, pretty much in a very similar way as described in this post on the msdn forum.

Solution: Long story short, you have to use svcutil to generate your proxy classes and data types with the /useSerializerForFaults attribute, this will cause the XmlSerializer to be used for reading and writing faults (but only those), instead of the default DataContractSerializer (which will still be used for the rest of the stuff).

Note 1: using the option /serializer:XmlSerializer instead of /UseSerializerForFaults on svcutil will cause the Faults to be wrapped in a sub-namespace (the same namespace they were defined in the xsd contract).

Note 2: setting the corresponding option item UseSerializerForFaults to false in the ServiceMap file does not give the same results (instead of generating duplicated properties it started generating duplicated attributes, two on each partial class).

This seems to be a genuine bug. Let's just hope it gets fixed because it's a pain to import stuff manually.

Note that if you kick it old school and import the service as web reference (the .NET 2.0 way) it should work fine as well, but for me this was not a choice.

12 comments:

Unknown said...

hmm...do you have any explanation what could be the case if the defined types (i.e. message:string, code:int) of my fault.xsd are not generated at all??
I just get a nodesField of type System.Xml.XmlNode[] and nothing more...

Btw, /UseSerializerForFaults is signaled as unrecognized option...

Unknown said...

@Juri

sorry, my bad - that'd be lowercase: /useSerializerForFault (but it works uppercase too for me!).

I've seen that behavior before (with nodes generated instead of types), you have to try and play with svcutil params. What happens if you explicitly set /serializer:XmlSerializer /importXmlTypes ?

Anyway - here's a list of svcutil cmd line args --> http://www.svcutil.com/?p=3

you might wanna have a look and see if there's something that could help you.

Let me know how it goes - made me curious.

Unknown said...

It's really weired. That's the command I'm using:
svcutil.exe /language:C# /serializer:XmlSerializer /useSerializerForFaults /out:IGroupsService.cs /n:*,MyCompany.MyProduct.MyModule *.wsdl *.xsd

With svcutil version 3.0.4506.30 I'm getting
"Error: Unrecognized option 'useserializerforfaults' specified.

I really don't know what I'm doing wrong...damn. Cost me already about 2 hours.

If I set the /importXmlTypes as you mentioned I get my fault type not generated at all. He then just adds a FaultContractAttribute with a not specified type onto the service method...

thx for your help

Unknown said...

Got it..damn stupid error from my part as I already assumed.
I didn't use the Visual Studio 2008 Command prompt but the svcutil.exe from C:\Program Files\Microsoft SDKs\v6.0\bin

So the /useSerializerForFaults option exists now.

Unknown said...

@Juri

cool - that explains it. :)
Did it solve your problem?

Unknown said...

No, the other problem isn't really solved yet. But at least now I'm getting an error

"Cannot import wsdl:portType"
"...thrown while running a WSDL import extension: System.ServiceModel.Description.XmlSerializerMessageContractImporter"
"Error: The datatype '...' is missing."

Although validating my WSDL + xsd files seems ok..

Unknown said...

@Juri

have you tried removing /serializer:XmlSerializer and keeping only /useSerializerForFaults?

Unknown said...

yes tried that also, no difference, it always gives me the error that the typ is missing. Really strange, also because I validated my WSDL successfully with a couple of other tools.

I'm going to post on Stackoverflow about this problem. Someone must have run into this problem before.

Unknown said...

cool - can you give me the link here? I'll up-vote you since it's a very strange problem and now I am definitely curious to see how it ends! :)

Unknown said...

Here's the link: *click*

Hope to get some valuable answers. Btw, saw you're from Italy. Me too :)

Unknown said...

Yes, a nice coincidence - I've seen that as well from your twitter account. Hope you get a solution to your problem :)

Tarek El-Mallah said...

I think to add this WSDL using visual studio 2008, it should support SOAP 1.1 , check the version of this SOAP using SOAPUI application or similar apps.