Interoperability issue between .NET 4.0 WCF service and .NET 3.5 client

Question

I upgraded a WCF service written in .NET 3.5 to .NET 4.0 Beta 1 by just using Visual Studio 2010 Beta 1 to convert the projects and change the Target Framework to .NET Framework 4.0 without any other code modifications. The new service was deployed on Windows 2008/IIS 7 and application pool with .NET Framework 4.0 Beta 1. Both the service and the client are coded by C#.

Here was what I found:

1)      The Visual Studio 2008 (Team System version 9.0.30729.1 SP with .NET Framework 3.5 SP1) cannot correctly generate classes of the client for the WCF service run on .NET 4. Although no error is reported, the list of classes apparently is incomplete. The generating process terminated at some point when it was parsing the WSDL. If I unchecked the “Reuse types in referenced assemblies”, it will generate more classes, but still incomplete;

2)      Using unit tests, with the client generated by Visual Studio 2008 from the WCF service run on .NET 3.5, to test the service run on .net 4, some unit tests failed with the error like: System.ServiceModel.Dispatcher.NetDispatcherFaultException: The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://schemas.msoutlookonline.net/services/ad/2008:Items. The InnerException message was 'Error in line 1 position 2209. 'Element' 'm_name' from namespace 'http://schemas.datacontract.org/2004/07/System.Globalization' is not expected. Expecting element 'm_cultureId | m_dataItem'.'.  Please see InnerException for more details. --->  System.Runtime.Serialization.SerializationException: Error in line 1 position 2209. 'Element' 'm_name' from namespace 'http://schemas.datacontract.org/2004/07/System.Globalization' is not expected. Expecting element 'm_cultureId | m_dataItem'..

 

Question:

1)      Is it a bug or by design when the WCF service using .NET Framework 4, the client that consumes the service should also run on .NET 4?

2)      Is it a bug or by design when the WCF service using .NET Framework 4, the client should only be generated by Visual Studio 2010?

3)      Does WCF service running on .NET 4 have a different WSDL from running on .NET 3.5? Means, updating the WCF service 4 will require recompile the client applications or services that consume this WCF service?

4)      Or, can I do something to make it work?

 

 

Thank you.

Answer 1

I figured it out. At least for my case, the .NET 4.0 WCF is not backward compatiable with the .NET 2.0/3.0/3.5 client. At least by design the new Microsoft class library does not support this.

The base reason is Microsoft rewrite the code of .NET framework 4. Not like .NET 3.0/3.5, .NET 4.0 is not based on .NET 2.0. The error message I got actually because the defintion of Serializing and Deserialized behavior of RegionInfo class, which are in the mscolib.dll, are different between .NET 2.0 and .NET 4.0. So the WSDL of these two classes are different.

I did not compare the entire framework so I did not know how many other cases like this RegionInfo class.

The workaround: since I only use one class that has the problem. I implement the RegionInfo class and the .NET 2.0 behavior by my code and specify the name space as http://schemas.datacontract.org/2005/07/System.Globalization and let all the references in my code to use the customized RegioInfo class. 

The .NET 3.5 client is now happy with the new service, because the WSDL are identical now.

Answer 2

Add one more note. The above "solution" will cause new problem. It will make .NET 4.0 client cannot consume the (.NET 4.0) WCF service.

So it is not a solution at all. Dot-NET 3.5 and 4.0 clients cannot consume the WCF service written by another. You can only use .NET 3.5 client to access .NET 3.5 WCF service; or use .NET 4.0 client to access .NET 4.0 WCF service. At least at the Beta 1 stage.

Answer 3

Got the same issue in Beta 2.

VS 2008 fails to generate most of the classes for .NET 4.0 WCF service.

Are there any resolutions for this?

Thanks.

---

Best regards, Alexander Efimov