Mixing .NET 3.5 with 4/4.5 assemblies in the same process

lysergic-acid picture lysergic-acid · Dec 10, 2012 · Viewed 26.8k times · Source

I'd like to migrate a .NET 3.5 WinForms based application to the latest .NET version (4.5).

The application uses "external" components (can be thought of as plugins) that are also currently .NET 3.5 based.

I'd like to know what runtime/core libraries are used in case we convert ONLY THE APPLICATION to compile using .NET 4.5?

Should this scenario properly work? (loading .NET 3.5 assemblies in a 4.5 process)? * The plugin assemblies are loaded via reflection.

How does the CLR runtime handle such a scenario? is this a safe practice?

Answer

Hans Passant picture Hans Passant · Dec 10, 2012

If you recompiled the main EXE of your app to target .NET 4.x or use an app.exe.config file with the <supportedRuntime> element to force CLR version 4 to get used then you'll have no trouble using both .NET 3.5 and .NET 4.0 assemblies. CLR v4 has no trouble reading 3.5 assemblies, it is backwards compatible. Not the other way around, CLR v2 can't read version 4 assemblies which is why you need the .config file if your EXE isn't targeting v4.

The only wrinkle is the dependencies that your 3.5 assembly has on old framework assemblies. It will for example ask for version 2.0.0.0 of mscorlib.dll. The CLR automatically translates those requests and replaces them with version 4.0.0.0. Which in general works just fine, the standard 4.0 framework assemblies are very compatible with the old versions.

Microsoft did however take the opportunity with 4.0 being a new side-by-side version and fixed old bugs that could not be easily fixed without risking breaking code that accidentally relied on the buggy behavior. They are very obscure bugs and it is pretty unlikely these bug fixes will byte you. You do however have to re-test your code to make sure.