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 be able to access it. Is this not the case? Any recommendations in terms of supporting applications in both environments?

EDIT: I realize that I’d need to install the .NET 4.0 Framework on the target system, are there other reasons why this won’t/shouldn’t work?

EDIT: Probably should have been more specific. We have a current, large/complex, application written in .NET 2.0 (ASP.NET be exact). We have a new set of integration tools and workflow items we are writting in .NET 4.0. We wanted to add one of the 4.0 created libraries to the .NET 2.0 project (currently in VS2008) and make use of a few of it’s methods. When we do this we run into problems, often cryptic errors relating to memory.

It would appear that both Earwicker and Brian Rasmussen are correct in the end. As I’m not too keen on exposing things via COM (not sure if this is technically COM or not but regardless) I think I will stick to the idea that the two are not ‘compatible’ and look to other means, which I think we have based on our specific needs. Longer term we will look to move the .NET 2.0 code up to 4.0.

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