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

Solution 1:

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.

Solution 2:

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.).