I have a type and an XML doc that deserialize fine using the .Net 2.0 and .net 3.0 RC1

However, using the RTM of 3.0, it will not deserialize. Now, it's possible this is our coding error. However, I thought 3.0 was entirely backwards compatible

Here's the lowdown:

1) Using "sgen /k /t:... " with the .cs files on multiple machines match as long as they have the same version of the .net framework. However, they differ significantly on different versions of the framework. (that is, between 2.0 and 3.0)

2) Our problem is that we had a root element serializing to a type that had the [XmlType(Namespace=)] attribute, rather than the [XmlRoot ... ] attribute.

While it may be an error to deserialize our type correctly, it was doing so before 3.0 RTM. Now it doesn't. Any light that can be shed on this would be much appreciated - we were under the impression that 3.0 was "2.0 + WinFX" , not "2.0 + WinFX + Breaking Changes"

Thanks!

There were number of bugs fixed in XmlSerializer for the Whidbey release (v2.0)

It is possible that you are running into one of them.

Could you post a simplified repro

Class definitions + instance that fail to Deserialize + error you get.

Thanks,

Elena

The error is not moving 1.1 to 2.0, or from 2.0 to 3.0, it's from the version of 2.0 available for XP to the version of 2.0 included in the box with Vista.

I've narrowed down the problem, but I'm not happy about what I've found... The issue is that the file version 2.0.50727.42 of System.Xml - the version available on XP - deserializes my type, but the System.Xml file version 2.0.50727.312 (the version on vista) does not. They both are "v2.0" FCL assemblies, but they behave differently.

You can see the simple repro and a better description on my blog entry about it: http://www.philiprieck.com/blog/archive/2006/11/22/933.aspx

I see now. You are running into a situation wirh anonymous types and [XmlRoot] attributes. V2 was released with a breaking change in handling of anonymous types, number of customers complained and Microsofr released a Hotfix to revert the breaking change to the V 1.1 behavior.

The 2.0.50727.42 has the bug, and 2.0.50727.312 has the bug fixed.

Thanks,

Elena

I see. So to recap, I'm running into the following:

• A breaking change was introduced between 1.1 and 2.0
• A hotfix was created for 2.0 to revert to the 1.1 behavor and not distributed outside of PSS
• This hotfix is applied on Vista, but is not publicly available for XP

This is more than a little disturbing. I can see a breaking change from 1.1 to 2.0 being a bit unnerving, but to break 2.0's behavior after it's been out in the wild for over a year seems worse - then to force distribution of that breaking change to one platform, but not make it available for another is... well, not right.

In order to make sure my application works as tested:

• using <requiredRuntime> or <supportedRuntime> in my app.config won't work, since both are 2.0.50727
• probing for the assembly version defining XmlSerializer (or System.Xml.dll) won't work, since they're both 2.0.0.0

I have to check the assembly file version

This is really a difficult issue: I believe that the Hotfix is available for all platforms, but user has to request/istall it explicitly: it is not forced (advertised) on user as a security update.

Potentially you could probe the file version and prompt the user for an update (still ugly), or you could edit the generate proxy to get rid of AnonymousType=”true”

I realize that it is not ideal, but at least it will work for majority of apps that do not dynamically re-generate classes.

Sorry,

Elena