If you have a .net application running on 2.0, test it on the 2.0 shipped in Vista, even if it has no UI.  .Net 2.0 on Vista is not the same as the 2.0 that's available on other platforms right now.

The Synopsis

  • On Vista (RTM), System.Xml.Dll's file version is 2.0.50727.312.
    On XP with either .net 2.0 or .net 3.0 installed, it's 2.0.50727.42
  • The serialization engine that creates xml serialization assemblies on the fly (via XmlSerializerFactory or XmlSerializer) creates markedly different assemblies
  • Things that deserialize fine on XP (which may be coded incorrectly, but run and pass all tests and fxcop rules) do not on Vista

 

Yes, really.    No, I don't know why.

The Issue

You can download a very small project that reproduces this issue if you want to follow along.   This application will run fine under XP with either .Net 2.0 or 3.0 (which installs .Net 2.0) installed and fully patched.   It will not run under Vista. 

What it does is read in this XML:

<?xml version="1.0" encoding="utf-8" ?>
<DummyType xmlns="tst"/>

Then it tries to deserialize like this:

XmlSerializer ser = new XmlSerializer(typeof(DummyType));
DummyType t = ser.Deserialize(reader) as DummyType;

into this type:

[Serializable]
[XmlType(AnonymousType=true, Namespace="tst")]
public class DummyType
{    
}

That's it.  Really.    You'll note that in the repro project, I have an app.config with the <requiredRuntime> element.  I wanted to; 1. Make sure that there was no version difference in the runtimes I was testing, and 2. point out that you can't future proof your code when people change functionality but leave the version numbers the same.

 

The background

We had a type that (through the evils of copy/paste) was attributed with [XmlType] instead of [XmlRoot].  But since the 2.0 framework on XP (and even Vista up through RC2) worked as expected, we didn't ever notice.   Until we ran it on Vista RTM - an exception is thrown immediately when deserializing from XML.

Trying to track it down, we found out that "sgen.exe /k ..." creates markedly different versions of the serialization code between XP and Vista.  I haven't done a full analysis of the differences (and I probably won't - real job and all that), so I don't know what other differences to expect.  Hopefully we just ran into an edge case, but like I said the code is completely different.

I'm not sure why, but it seems the 2.0 assemblies shipped with Vista's 3.0 are different than the 2.0 assemblies in either the 2.0 or 3.0 redist available from Microsoft for other platforms. (wheh, this 3.0 versioning is fun, isn't it!)

 

The Rant

What would a customer think?  "This dumb app isn't Vista compatible" or "Stupid Vista  broke my applications".  If I'm lucky, they'll check for a fix on our website. 

Really, I expected some UI problems going to vista, but not XmlSerialization issues. 

I insist on compatibility - if 2.0 runs code -even if it's wrong- , then 2.0 should always run that code.  I should be able to use <requiredRuntime> to make sure that my code doesn't go into an environment with an untested platform, even one that hasn't been released.   Don't break my running and deployed application.

I thought we collectively learned our lesson on this one - A contract is immutable once published.  With something like the .net framework, the contract isn't just the signatures of the API!  I'm sorry, I know it sucks for the FCL team and makes their lives harder, but for .net the contract includes all of the functionality, quirks, and side effects.    If you change anything, change the version number.

The Hope

However, I'll be understanding if compatibility must be broken for a security update.   Yes, I'll recommend patching 2.0 even if it breaks my applications when there's no other choice to fix a possible vulnerability.  Does Vista have a security patch applied to 2.0 that isn't available yet?  That would make me much less angry -  So that's what I'll hope.