Share via

CLR Side by Side and Compatibility

  • Article

CLR side by side is often quoted as a way to combat compatibility issue. But does it really work?

Today CLR side by side means two things:

1. Two versions of .Net framework can be installed side by side. Installation of a new version of .Net framework will not disable previous version of .Net framework.
2. Two processes can load different versions of CLR.

But CLR side by side stops right there. Once CLR is loaded into a process

1. It cannot be unloaded
2. No other version of CLR can be loaded into the process.

In other word, one, and only one CLR can be loaded ever into a process.

This restriction has the following consequence:

When the first time managed code is invoked, unless there are hints about which version of CLR the process wants, the latest CLR will be loaded.

This applies to COM interop, as well as IE controls.

Hints include app.config file if any, the version of CLR the process exe is built with if the process exe is written in managed code.

An assembly dll cannot be served as a hint.

Take Outlook as an example. Say both .Net framework v1.1 and v2.0 are installed on the machine. When Outlook activates a managed add-in, even the add-in is written in .Net framework v1.1, v2.0 CLR will be loaded into Outlook.

The reason is simple. V1.1 CLR can not load v2.0 assemblies. Activating an add-in built with CLR v1.1 does not mean you will never want to activate another add-in built with CLR v2.0. The *only* sane choice is to load the latest CLR.

Unfortunately due to framework unification policy, the latest .Net framework assemblies will be used along with the latest CLR. Due to changes in .Net framework assemblies or CLR, v1.1 assemblies may break running under latest .Net framework.

V1.1 assemblies may still run under newer version of .Net framework than the one it is built against. A trivial example is a v2.0 application references v1.1 assemblies. Since v2.0 application will use v2.0 CLR, the referenced v1.1 assemblies will still run under v2.0 CLR.

What do all these mean?

It means at least one thing if not more: CLR side by side does not make compatibility any easier.

Now go back and do your compatibility homework, even “Compatibility is evil.”

Comments

  • Anonymous
    November 21, 2005
    Good article, simple and concise thanks for the information