Can I use a .NET 4.0 library in a .NET 2.0 application?

Question

I\'m running into some problems using my .NET 4.0 libraries in .NET 2.0 applications. I guess I was under the impression that being a Windows DLL, my other .NET apps would

Answer 1

Your assembly compiled for .NET 4 will contain references to other .NET 4 framework libraries that are not present in .NET 2.0.

If you want to have your applications compatible with .NET 2.0 you can use Visual Studio 2005 or target your projects to .NET 2.0 if you are using Visual Studio 2008 or 2010. Of course, if you target your projects to .NET 2.0 you will not be able to take advantage of .NET 3.5/4 features.

Answer 2

I've just published a post basically what Daniel suggested.

How to use a .NET 4 based DLL from a .NET 2 based application

Source Code and description at: http://code.msdn.microsoft.com/Using-a-NET-4-Based-DLL-bb141db3

Answer 3

Looks like the in-process side-by-side feature which was added to CLR 4 wouldn't help in this case since the he wants to use a .NET4.0 library in a .NET2.0 application. As far as I understand it, in-process SxS would be helpful if the case was the opposite (consuming a .NET2.0 in a .NEt4.0 application) as the CLR of the 4.0 will work side by side with 2.0 in the same process..

Answer 4

Please note that version 4.0 is more than just additional assemblies. The runtime itself has also been changed in this version (new concurrent GC mode, lots of changes to the thread pool, mscorwks.dll is now called clr.dll, etc.).

Answer 5

I had a similar problem with my application where I was not able to reference an API, that was using .net 4.0 components.
To resolve this I created a new class library project that was referencing my .net 4.0 project and then called that new assembly from my .net 2.0 project. I mapped the data coming back from .net 4.0 project to be used by my .net 2.0 project.
That resolved my issue.

Answer 6

Yes, this is perfectly possible. You just expose the components written in 4.0 as COM objects. The 2.0 hosting application just uses them as COM objects and has no idea whether they are native, 2.0, 4.0 or whatever. COM is the common interface that both runtime versions have to implement identically.

The new in-process SxS support in 4.0 means that when the 4.0-based COM object is loaded, it pulls in the required runtime instead of trying to run on the 2.0, so both runtimes are present in the process managing their own objects. Although you can't directly pass CLR objects between them, you can pass COM interfaces, and the CLR transparently wraps your objects in COM interfaces for you.

I don't know if you can make a single interop assembly for both versions to work from. But clearly you could write an interop assembly in C# in 2.0, export it to a .tlb, and then import it into an assembly in 4.0. That gives you two matching interop assemblies describing identical COM interfaces. (Or just build the same C# source in each version's assembly project).

Bonus Update: Will the resulting application be COM-based (with whatever problems that entails)?

It depends how you look at it. Authors of components will be making them as COM components. So the host application needs to locate and load them as COM components. This means fooling around with the GAC, the registry or SxS manifests, which is a lot less clean than just telling component authors to drop their assembly in a certain directory so you can load it with reflection.

And it has an impact at runtime: when the host has a reference to a component, there will be not one but three objects involved. The host has a reference to a RCW, which has a pointer to a COM interface implemented by a CCW, which in turn holds a reference to the actual component. The CCW in the middle is a reference-counted COM object, and the host's RCW has a finalizer that calls Release on the CCW, and when it is destroyed it deallocates the GCRoot that is keeping alive the actual component.

This means that - with a sufficiently complicated arrangement of callback pointers, etc. - the system may end up with circular reference counting problems, where a disconnected "island" of objects are all holding references to each other and so they never get deallocated.