Question

We create a plugin for a software that was built for .NET 3.5. In this plugin, we reference a third party .DLL that works for .NET 3.5. The main software is now built to .NET 4.0 and the third party .DLL has been split up into two .DLL.

What we want to avoid is having two seperate solutions with almost the exact same code (one built to .NET 4.0 referencing the 4.0 DLLs and one built to 3.5 referencing the 3.5 DLLs). Not all of our customers are going to upgrade to the newest version of the software we create plugins for right away, some may wait years.

QUESTION EDITED:

Is there any way to continue to build to .Net 3.5 referencing the 3.5 DLL, and then at run time perform some assembly resolve to load the two .Net 4.0 DLLs in the place of the original one?

We want/need to keep building to a 3.5 framework so that previous versions of the main software will continue to load our plugin. If we build to 4.0 then the older versions will give an error when trying to load our plugin because its build to a later framework.

Answer 1

This assembly is built by a runtime newer than the currently loaded runtime

That’s crystal clear, your EXE loaded an earlier version of the CLR. Only the .NET 4 version of the CLR knows how to load an assembly that was built to target 4. The metadata format has changed in 4, the old CLR doesn’t know how to read it.

Either rebuild your EXE to target 4 as well or provide a app.exe.config file that forces your program to run with the newer version of the CLR. It should look like this:

<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0" />
    </startup>
</configuration>

Some testing is required, .NET 4 is highly compatible but it does have some bug fixes that you might accidentally rely on.