Take the .NET Framework 2.0 Compatibility Challenge

Lots of buzz around the issue of .NET Framework 2.0 running your current applications…   I could wax on about why this kind of compatibility is important, what we have been doing to make sure your apps keep working, how side-by-side really helps here, why editors use sensational headlines etc.  But I thought in the age of a fully democratic and organic press I would leave this to you. Rather than believe me, or the vagaries of the press… why not gather our own data and compare notes! 


So, here is my invitation to get involved in an open reporting of compatibility issues.   Here is what you do. 

Step 1: Read through Compatibility Testing Scenarios

Step 2: Do the 5 tests it suggests (or any subset you have time for)

Step 3: Blog your results and tell us what you think!  Good or bad, blog it out (be sure to also fill out the survey for our internal bean counting too)


I am sure there will be some apps that the platform fails on, for those be sure to submit a bug… I want to make sure we address as many of those as we can before we ship.  I am also equally sure some apps just work…


Thanks and let the challenge begin!


Comments (8)

  1. My brother and I were both very upset by the headlines. Microsoft is being very open and helpful in this case, and trying to make Whidbey a great product, compatibility-wise, but the media makes it seem like a few minor changes to the framework’s behavior will bring the end of the world. After reading Raymond Chen’s blog for a while, I must say I’m surprised at how far Microsoft bends over backwards so much to support old (and often buggy) applications. But any time there is a compat problem "Micro$oft" is automatically scheming.

    I think the headlines missed the point completely. Many compatability problems can be solved by side-by-side framework versions, but due to the extra care the BCL team is taking, SxS should not be needed except in rare cases.

    The big problem with the headlines is that one of our customers will undoubtedly read the article (or worse just the headline) and fail to fully grasp the situation. If we mention that we will be moving our software product to .NET 2.0 (which I’m sure we will be), a red flag will go up and they will complain because some article said that installing 2.0 would break 1.1 applications. The same thing happened when we moved from COM to .NET, because of some bad publicity given during early betas.

    The only major issue I see is Serialization between versions (especially System.DateTime), and it has already been stated that the major issues will be fixed with a service pack to .NET 1.1. As for manually checking framework version numbers (the other big issue, according to the whitepaper), people who do this carelessly deserve to have their application break. I certainly do not want to see the Framework lie about its version, or install into a different folder, because that causes problems for those of us who use the version numbers properly.

  2. Ashkan says:

    You will hate me for this, but you know what I have noticed? Microsoft and all things about it (developers, managers, workers …) will not pay attention to anything like compatibility unless some important website says something "bad" about them. It’s then that you will see Microsoft as a unified army tackling the problem head on, without any fears and they will not rest until they find the best solution.

    Here’s my question, though, why is it that Microsoft does not care about these issues, if nobody points it out?

    You will definitely disagree with me, but think about it. Imagine that you were not an employee of Microsoft for a second and think about all the stuff that is happening. Look at IE for example. Microsoft didn’t give a rat’s a** about it because it had over 90% of the market share, and now since other competitors have been gaining some success in taking away users, all of the sudden IE 7 on XP is not "technologically impossible," and it will have tabs and PNG support as well. Why is it that Microsoft will not try to innovate, if it has no competition?

  3. BradA says:

    TheMuuj – You are right, we are doing a ton to make sure apps keep working and side-by-side is a big part of that. I too share your concern about so called “app hacks”.. no doubt it is a balance.

    Ashkan – you raise a good point in general… Of course Microsoft responds to competitive pressure, and we respond to our customers when they ask laud-and-clear for something. Look at XP SP2 for example.. we put Longhorn on hold to do SP2 because customers clearly told us what they wanted. As far as doing something because the press says so… that is a different story in my book. I love the press, they help educate the community which is great, but the only action I personally would take because of a press story is to clean up any mis-information. As a testament to that, notice the whitepaper and survey were up BEFORE the press story broke…

  4. Ashkan: You bring up IE, which is admittedly a sore spot for me, as I’m a big supporter of web standards.

    But a lot of the problems with IE are caused because the IE team seems to feel that backwards compatability with old versions is more important than compatability with the standards, which does fit with the overall commitment to compatability at Microsoft. With IE, they certainly CAN have it both ways, as has been done in the past with DOCTYPE switching, but I’m not going to waste time discussing it here.

    As for .NET and C#, I hold their team in much higher esteem than the teams of most other Microsoft products. Their openess throughout the .NET 1 betas and now in the Whidbey betas is a refreshing change from the Microsoft that most people think about.

    And unlike IE, the .NET team only has to worry about:

    1) Compatability with older versions of .NET

    2) Compatability with the ECMA spec (which only covers a subset of the BCL)

    3) Compatability across *supported* platforms (Windows 2000 vs XP, Home vs Pro vs Server, x86 vs x64 vs IA-64).

    There’s no bigger picture to worry about…Any other .NET implementations (like Mono) have the burden of making their versions act like Microsoft’s, not the other way around (although standardizing more of the libraries might be nice).

    So you cannot fairly compare .NET to IE.

    I think .NET has, for the most part, maintained a fantastic level of compatability. There are actually a few places where I wouldn’t mind compatability being broken for the sake of a better set of libraries, but I don’t push for them because I know Microsoft won’t intentionally break applications.

    In the few places that compatability *has* been broken in 2.0, I’m happy with the change, especially if it means fixing a bug or meeting the ECMA spec. I brought up the DateTime issue earlier, which I suspect might break a lot of apps that serialize data in the short term, but I feel this is for the best. There are too many APIs that assume you’re passing a local time or a UTC time, and the problem with the ambiguous daylight savings time (e.g. 1:30 PST vs 1:30 PDT) has always been a problem for me before.

    As a developer, you should never rely on behavior that you think might be a bug, and you should report the bug and work around it so that your app will not break in future versions. I’ve done so with an ArrayList.Adapter bug, and I seriously hope nobody else is relying on the obviously buggy behavior.

    And you should also never rely on internal implementations or methods that are documented as being for internal use (although I question why these should remain public, especially with friend assemblies), but these rules are invariably broken, and I’m sure Microsoft will be at fault in the eyes of said developers.

  5. Jeff Parker says:

    You know Brad, I just got to tell you I downloaded the BreakingChanges.chm file from msdn and looked at it. If people would bother to look at what and why on the breaking changes then understand there is a reason for them.

    One Breaking change that had me excited, xhtml in now more standards compliant.

    First people complain that Microsoft doesn’t adhere to standards, then they complain when they make them standards compliant and that it is a breaking change. I have to say I think .net 2.0 is on the right track the breaking changes I have seen are really bug fixes that NEEDED to be done. So Brad I hope to see a few more breaking changes along these lines. All you are doing is making my apps better. I can’t imagine a time where I do not have to rewrite an asp.net control to make it standards compliant. I am tickled pink.

  6. Ashkan says:

    I didn’t mean to compare .NET to IE. I was just trying to point out an example. As a developer, I do understand that I have to worry about backwards compatibility and standards in the applications I develop, but here’s a suggestion: (Just off the top of my head): Wouldn’t it be a better practice if Microsoft would go by the standards from the get go? Instead of creating something that doesn’t comply with the existing and the well established standards, and then worrying about them is not a good way to do things. Now I’m not suggesting this is what is happening at Microsoft. I’m just suggesting this, since I care about the platform that I use and develop applications for.

    You know what I have always wished for? Just a direct way for me to get my opinions across to you guy at Microsoft. You know, developer blogs are great, but not everybody gets to see them. Besides they are mostly for technical purposes. I wish there was a forum or a mailing list of some sort that I could go to and say something like "I found a problem with X and Y on Windows Z."

  7. Ian Ringrose says:

    I have submitted a bug on backwards compatibility, it has been up since the 11th May 2005 but has not been looked at yet. The fact that I only had to change one line code and the new code worked on both .NET 1 and .NET 2 made me reasonably happy. It also proved the value of me having unit tests for all the code I have written.



    http://www.ringrose.name <- email address on website

  8. Surupa says:


    We apologize for the delay but the breaking change you reported on May 11 is being actively investigated. In v1.1 the contructor for DirectoryEntry had its default authentication type set to None and this has indeed changed in v2.0. We made this breaking change due to security reasons and may not be able to revert it. The workaround is to explicitly set the AuthenticationType to None instead of rely on the default value. For code that has shipped, we’re currently considering some mitigations. You will certainly hear back from us soon when the issue you reported gets resolved in our database.

    We appreciate your patience.

Skip to main content