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

Question

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 1

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.

Answer 2

All assemblies will use types from .NET Framework which application targets.

Here is a simple test:

Project 'Net2Library' which is a .NET Framework 2.0 Class Library with following class:

using System;
using System.Collections.Generic;

namespace Net2Library
{
    public class Class1
    {
        public static List<string> GetStrings()
        {
            var strings = new List<string>();
            Console.WriteLine("From Net2Library: {0}", strings.GetType().AssemblyQualifiedName);
            return strings;
        }
    }
}

Project 'Net4Application' which is a .NET Framework 4.0 Console Application that references Net2Library.dll and has following class:

using System;
using Net2Library;

namespace Net4Application
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("From Net4Application: {0}", Class1.GetStrings().GetType().AssemblyQualifiedName);
        }
    }
}

Console output will be:

From Net2Library: System.Collections.Generic.List`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 From Net4Application: System.Collections.Generic.List`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]], mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

You may also check out following resources: .NET Framework Assembly Unification Overview and Assembly Binding Redirection.

Answer 3

If you have a 3.5 assembly referenced from a 4.5 executable, both assemblies will run in the 4.5's CLR environment. However, the 3.5 assembly will target the v3.5 libraries, not the v4.0 (although the 4.0 libraries will have all the same functionality as the 3.5, and more).

So, at least in my experience, if you want assemblies targeting 2.0-3.5 and other assemblies targeting 4.0-4.5, you will need both 3.5 and 4.5 framework versions installed on the client computer. 3.5 is fully backward-compatible back to 2.0, so you can have 3.5, 3.0 and 2.0 all running in one environment. 4.0-4.5 is compatible with most older code, but there are some breaking changes (CAS is one case I stumbled on recently), and you have to explicitly target 4.0 (or set up a SupportedRuntime app.config key).