CLR 2.0: Compatibility and Side-by-side

As I talked to customers (internally and externally) it is clear that our story around compatibility and side-by-side is not well understood.  Here is a very brief description to help us get on the same page:


Compatibility: We are working very hard to make sure that V1.x apps just run on V2.0.  We have a full appcompat lab, with many real world applications and a full compat test suite.  I think we are pretty good for the Beta2 drop we are working hard on now and will get better with RTM as we get more compat feedback from you.  
However, perfect compatibility is essentially impossible.  Sometimes apps make invalid assumptions about what the platform will do in certain situations.  And there are also cases where, in order to secure the platform, we must make breaking changes.  So we know we needed a backup plan.


Side-by-side: We have also done all the work to make sure V1.0, V1.1 and V2.0 can all be installed on and run on the same machine at the same time.  This means if an app happens to be in one of the corner cases that is broken on V2.0, the fix in almost all cases is to simply install V1.x on the machine.  Our policy is that if an app was developed with V1.x and run on a machine with only v2.0 on it, the app will be run on V2.0.  If V1.x and V2.0 are on the machine the app will be run on V1.x in order to give the highest guarantee of compatibility as possible.


Clear as mud?  Does this seem like the right track?

Comments (23)

  1. Excellent news. From what I hear Java has oodles of problems with differing versions of the runtime.

  2. a. says:

    .net framework has an annoying habit to register itslef as the default handler during the install.

    so when you want to install a new version of the framework you end up wit hall previous apps reregistered to the new version. this can be a pain when you have a lots of sites hosted on that computer.

    are you going to make the registation optional?

  3. I understood that with Longhorn, there’d be no SxS. Is this incorrect?

  4. Matthew W. Jackson says:

    My plan is to uninstall 1.1 as soon as the RTM of 2.0 comes out, unless I find a critical application that simply does not work and will not be updated, which seems unlikely due to all the compatability work.

    The only major potentially-breaking changes are due to remoting, which might be a problem if I have an app that remotes to a 1.1 app on another machine. But you guys said there will be a service pack for that, so all is well in .NET land.

    I do not currently have .NET 1.0 installed on any of my production machines, and since I’m likely to be adopting .NET 2.0 as soon as possible (it’s hard to pass up), I probably will have no need for .NET 1.1 anymore.

  5. Michael – We will install only v2.0 on Longhorn by default, you can however add V1.x to Longhorn if you need to. So they will run side-by-side on LH if you need that.

  6. Grim says:

    One problem here.

    If I have 10 apps/services, all originally written for 1.1, but they all work fine on 2.0, fantastic.

    But then if I need to install #11, and it won’t run under 2.0, I have to install 1.1. Seems reasonable.

    Except that now all 10 of my apps that I want running under 2.0 are now running under 1.1, instead.

    It would be preferable to have a mechanism that allows selection of individual apps that have to run under 1.1, and everything else runs under 2.0.

  7. Matthew W. Jackson says:

    I thought that a combintion of machine config and app config settings *could* force most apps to run on 2.0, but individual apps to run on a specific version.

    You can also configure an app to run on the newest version of the framework available out of a list of supported platforms, I believe. Many apps ship with config files that do this (some even run on Whidbey now).

  8. AT says:

    Bad .. Bad …

    If you did this once – for 1.1 -> 2.0 it will be hard to change during 2.0 -> 3.0.

    If developer coded his application once for 1.1 – he must redistribute it with 1.1 and does not care about existence of newer versions of software.

    I know some companies are still using Access from Office 95 (will you trust in this??) for their line-of-business application and pretty happy with this.

    Another example is MS-DOS-based applications used world-wide at different companies.

    These clearly show that doing side-by-side will be okay.

    IMHO, you do not need to spend your time designing future frameworks to be backward compatible. Make everything to work correctly/best. Do not use "compatibly" as an apology for tradeoffs you make.

  9. Grim, see "Targeting a .NET Framework Version" in the .NET Framework SDK at It explains how you can require a certain version of a framework for your application.

  10. Matthew W. Jackson says:

    Some level of compatabilty is nice…it keeps us from (in the future) having to run .NET 1.0, .NET 1.1, .NET 2.0, .NET 2.1, .NET 2.2, .NET 2.3, .NET 3.0, etc., side by side.

    Disk space isn’t an issue (20+ MB is nothing), but as the number of managed applications increase, side-by-side versions will hurt performance due to more page faults and less sharing of NGen’ed native code. It pays to have all programs trying to run on the same version.

    But I don’t mind minor-to-medium breaking changes from major versions…But, except for in extreme circumstances, I do not want to be forced to run two minor versions side-by-side. I’m glad I’ve never needed 1.0 and 1.1—or I would have been upset.

    Still, 2.0 could have some major breaking changes and be fine by me. I’d still only be up to 2 framework versions. I can’t count how many Java runtime versions I have….at least I can find all .NET versions in one place. Many programs tend to have their own local copy of Java, to avoid versioning problems I suppose.

  11. Andrew Webb says:

    Safer, simpler, easier and cheaper to say that an app. requires the installation of the runtime it was built against. Are customers really calling for 1.x apps to run on 2.0 Framework ? Backwards compatibility in this regards seems to be a waste of time IMHO since we’ve got SxS.

  12. Andrew, there are a few issues:

    (1) Not every app wants to carry the redist, but they want the broadest reach possible

    (2) It is in Microsoft’s interest that as many applications as possible run on Longhorn right out of the box, but we don’t want to bloat the Longhorn OS will all previous versions of the .NET Framework

    (3) Perhaps most importantly, each process can have only one CLR, so that means any add-in written against V1.1 would not run in a process that has 2.0 loaded. For example, any managed code activated via COM will run on the latest runtime.

  13. Andrew Webb says:

    Brad, re. (1) and (2), I’ve suggested elsewhere that it would v. nice to have a JIT installer (aka lazy installer) for the runtime. Any attempt to run or install a .NET executable would pull in the version of the runtime that it targeted just-in-time if it was missing. Then no app would have to carry the redist (if it didn’t want to), and Longhorn wouldn’t be bloated out-of-the-box. A reasonable idea ?

  14. John Wood says:

    To what degree will we be able to write stuff in VS.Net 2005 and have it continue to run on 1.1? Is there any kind of code compiled for CLR 2 that can continue to run (or be forced to run) on 1.1, or is the IL fundamentally different? Does VS.Net 2005 have a way to target 1.1 instead of 2.0?

  15. BradA says:

    John – The IL is not fundamentally different but there have been enough additions to the framework, VS and compilers that it would be very hard to write an app in VS2005 to run on V1.1 of the .NET Framework. The best way to target V1.1 is to use VS2003…

  16. Hi Brad,

    Not sure if this is the correct place to be asking but I’m hoping you will know.

    I’ve been looking for specs on the CLR/CLI 2.0 but I can’t find them anywhere. Are such documents available yet?

  17. <doc><div xmlns="" style="PADDING-RIGHT: 0in; MARGIN

Skip to main content