I have an multiple assembly C# Excel addin which passes embedded interop types across assembly boundaries. When I run this in an Excel process configured to use .NET 3.5, everything is OK. When I run this in an Excel process configured to use .NET 4.0, only controls with application logic defined in the addin assembly itself load. I think I understand why, since the handling of embedded interop types changed significantly in .NET 4.0, so that they must not cross assembly boundaries. What confuses me is that I thought in .NET 4.0 multiple instances of the CLR could be hosted in a single Windows process. If my addin targets .NET 3.5, why can’t it just run in a .NET 3.5 CLR instance owned by Excel? Why is Excel trying to run my addin in .NET 4.0? It’s not really an option to rewrite the addin, but it needs to install for a client who also use .NET 4.0 addins, so it’s not OK to play with registry keys or the Excel.exe.config files… Any help will be REALLY appreciated!
I have an multiple assembly C# Excel addin which passes embedded interop types across
Share
The answer to the question in your title is ‘yes’. The .NET runtime version 2.0 (which is the runtime version used by the .NET Framework 2.0, 3.0 and 3.5) can run side-by side in a process with the .NET runtime version 4.0 (which is the version number that will also be used by the upgraded .NET Framework 4.5).
However, the VSTO case is not so simple, since there is interaction between Excel and the VSTO runtime to decide what to load. VSTO 4 basically includes separate versions of the Office extensions targeting .NET 3.5 (under the .NET 2.0 runtime) and .NET 4.0. Depending on which version of the VSTO 4 office extensions you target, you uses classes (compatible with older VSTO) or mainly interfaces, so the VSTO API design and your code is a bit different too, depending on which version of the VSTO 4 office extensions you use. Then deployment and loading of your VSTO add-in depends on which version of the VSTO Office extensions you target.
So the version of the .NET runtime that your VSTO 4 add-in loads in is linked to how you made the add-in. Read more here: http://msdn.microsoft.com/en-us/library/bb608603(v=vs.100).aspx and http://msdn.microsoft.com/en-us/library/ee712596.aspx.
If you have other COM components, it could be that the COM components are activated in a different version of the runtime (say in the 2.0 runtime) and are then not accessible from the 4.0-runtime based add-in. The way COM interop type changed in .NET 4.0 would typically make things work better, since the runtime now correctly identifies types defined from different assemblies as ‘the same’ based on GUIDs etc.
To make life easier, I can also suggest Excel-DNA (which I develop). It is a free and easy add-in library for making full-featured Excel add-ins in .NET, without using VSTO. Excel-DNA allows you to target any version of Excel, and any 2.0+ version of .NET.