Errors in Proxy Generation while using DataContractSerializer

Topics: General Discussion Forum, July and December Releases Forum, Service Factory Modeling Edition Forum
Jul 9, 2008 at 3:09 PM
I wanted to post this so everyone can benefit from this. I spent a lot of time trying to debug this issue. We never had problems generating a proxy from both Service factory or SVCUtil.exe. The proxy was just fine and we used DataContractSerializer. All of a sudden our proxy generation is falling back to XmlSerialization and is missing lot of data contracts in the proxy. This is a known issue, XmlSerializer won't serialize many data contracts such as Enumerations and such. There is not a lot of information about this issue on the web and I feel the Microsoft team could have done a better job in telling us what exactly is causing this problem.

All validations work fine and isWrapped flag is set to false from the beginning and the proxy generated fine. Some new operations are causing this problem. It could be very well some long operation name that could be causing it. So I searched for IsWrapped = false and replaced all instances to IsWrapped = true and then it just worked like Magic, I was able to generate proxy using DataContractSerializer. This might have to be done for only one message contract but I just did for all message contracts just to keep it consistent.

So please do not waste much time and apply this fix for faster resolution if your proxy is falling back to XmlSerializer all of a sudden.

Jul 10, 2008 at 7:43 PM
Thanks for the contribution RouteCoder, we'll look into it!
Jul 11, 2008 at 9:04 AM
I've had this problem too. My proxy was correct when manually generating it with svcutil.
May 26, 2009 at 10:03 PM

This is terribly frustrating.  I have spent hours trying to debug an issue very similar.  I created a project in VS2008, Vista, and the binary install of WSSF: Modeling Edition.  I have been working with this project just fine for several days now.  I've been testing my service and getting data from my database, everything worked fine.  Then I added a new operation to the service that has multiple parts to both the request and response messages.  I set IsWrapped=true and am using DCSerializer.  Suddenly I started getting build errors from my proxy that one of my types is not defined and then others are being defined twice.

Error 2 The type or namespace name 'FooList' could not be found (are you missing a using directive or an assembly reference?) C:\Users\User\Documents\Visual Studio 2008\Projects\Bar\Foo.Bar\Tests\Foo.Bar.Client\MainForm.cs 17 17 Foo.Bar.Client

Error 3 The type 'Foo.Bar.Client.BarManagementProxy.Foo' already contains a definition for 'Id' C:\Users\User\Documents\Visual Studio 2008\Projects\Bar\Foo.Bar\Tests\Foo.Bar.Client\Service References\BarManagementProxy.cs 672 20 Foo.Bar.Client

Then I read this thread and set everything to IsWrapped=True and it still didn't work.  Then I removed my new operation and it worked again.  I added the operation back and it was OK, though I had not added my parts to the messages yet.  I started adding things back one at a time and when I got to the point where I added the second part to one of the messages and set IsWrapped=true, it started failing again.

What is going on here and how can I get around it?  I can't find anything to fix it.

May 27, 2009 at 12:19 AM

I finally got this working by removing all of my messages that had more than one part to it.  Then I added them back in one at a time until it broke again.  I noticed it was working when I had one message with multiple parts and IsWrapped=true.  As soon as I created the second it broke.  That's when i realized the second message I was creating was essentially identical to the first, just with a different name.  So I had my second operation just use the response message from the first operation.  Now it works.

But does this make any logical sense?  I can repro this over and over.

May 27, 2009 at 2:27 AM

You can check if the namespace and ReplyAction of both messages are the same (likely a naming clash).

From another thread;

WCF services share the contract not the type. So this contract is expressed using WSDL which is automatically generated by looking at various attributes in your service contract, data and message contracts. Now it is important to understand that if you define two interfaces and annotate them with the ServiceContract attribute, from your programming constructs perpective you will realize that they are distinguishable. But the ultimate language – WSDL does not know about C# interfaces. And if there are two services with the same name you should use two different XML namespaces to make them distinguishable.

More on this thread (bottom post):