Add support for .NET Core and .NET Framework side-by-side in same process

[JoshTefay]

Currently, it's not possible for applications to host both .NET Framework and .NET Core CLRs together in the same process. This creates an impediment for applications that need to load components that can use either runtime. Having support for this would be particularly useful in COM scenarios.

The recent announcement that VSTO will not be updated to support building Office add-ins using .NET Core (#5156) mentioned the lack of side-by-side .NET Core/.NET Framework support in the same process was the technical reason for this. If SxS support was implemented then it could be possible to build Office add-ins using .NET Core, even if VSTO was not updated.

Please give this serious consideration as there is a large Office developer ecosystem that is currently stranded on .NET Framework 4.8.

[AaronRobinsonMSFT]

@JoshTefay This is a long standing limitation for NET Core and .NET 5+ and at present considered "by-design". I would recommend moving this to the dotnet/runtime repo where we have a few issues discussing the topic. The latest is https://github.com/dotnet/runtime/issues/49686. I realize trying to determine where to file these issues is very confusing, but in this case I think the dotnet/runtime repo will get better visibility.

[AaronRobinsonMSFT]

Another discussion with more technical details can be found at https://github.com/dotnet/runtime/issues/12018.

[arknu]

The same issue also happens with multiple versions of .NET 5+ in the same process, see https://github.com/dotnet/runtime/issues/49686

[JoshTefay]

@AaronRobinsonMSFT thanks. Could you please move this issue to the recommended repo? I don't see an option to do this.

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @vsadov See info in area-owners.md if you want to be subscribed.

Issue Details

---

Currently, it's not possible for applications to host both .NET Framework and .NET Core CLRs together in the same process. This creates an impediment for applications that need to load components that can use either runtime. Having support for this would be particularly useful in COM scenarios. The recent announcement that VSTO will not be updated to support building Office add-ins using .NET Core (#5156) mentioned the lack of side-by-side .NET Core/.NET Framework support in the same process was the technical reason for this. If SxS support was implemented then it could be possible to build Office add-ins using .NET Core, even if VSTO was not updated. Please give this serious consideration as there is a large Office developer ecosystem that is currently stranded on .NET Framework 4.8.

Author:	JoshTefay
Assignees:	-
Labels:	`area-Host`
Milestone:	-

[govert]

@AaronRobinsonMSFT In the recent .NET 5+ / VSTO post (https://github.com/dotnet/core/issues/5156) you say

[...] .NET Core/.NET 5+ cannot work together with .NET Framework in the same process and may lead to add-in load failures.

However, previous threads, in particular your comment here: https://github.com/dotnet/runtime/issues/12018#issuecomment-551179800 said (about the same scenario of .NET Framework + .NET Core / .NET 5+ in a process):

It was not the intent of the statement to be so restrictive, but rather to convey the scenario has severe limitations with respect to diagnostics and the interaction between the two runtimes. I will update the documentation to provide the correct clarity and hopefully avoid confusion and concern about the associated scenarios.

My limited testing so far is that a combination of .NET Framework and one version of a .NET 5+ runtime in a process works and my understanding is that this is a supported scenario, subject to the limitations pointed out by @jeffschwMSFT here https://github.com/dotnet/runtime/issues/12018#issuecomment-549062371

Here are a few scenarios that are not supported with full fidelity:

• Assemblies loaded into .NET Framework are not visible in .NET Core and vice versa
• Debugging does not work well (you can only debug one runtime – not both of them at the same time)

The current documentation for COM Interop here: https://docs.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com was indeed updated to be consistent with this previous discussion:

Additionally, loading both .NET Framework and .NET Core into the same process does have diagnostic limitations. The primary limitation is the debugging of managed components as it is not possible to debug both .NET Framework and .NET Core at the same time. In addition, the two runtime instances don't share managed assemblies. This means that it isn't possible to share actual .NET types across the two runtimes and instead all interactions must be restricted to the exposed COM interface contracts.

And to be clear, for the moment different .NET Core/.NET 5+ versions cannot be simultaneously loaded into a process, but that is a different issue and a significantly smaller restriction.

If there is new technical information about limitations in the scenario with .NET Core/.NET 5+ and .NET Framework in the same process, maybe you can expand a bit. Bit I think it would be really surprising and bad if there are now serious problems with this.

Otherwise, if it is still supported to run the combination in process, maybe an explicit comment in the .NET 5+ hosting documentation to this effect could be added to clarify things (or if I have missed it, a pointer would correct the misunderstanding raised in the original post in this thread).

[AaronRobinsonMSFT]

@govert Thank you for asking about this. I agree this area could be described better. Your reading of my statement on dotnet/core#5156 is fair. I think we can agree the word in question here is "support" – as in what are the guarantees between a .NET Framework instance and a .NET Core 3.x/.NET 5+ instance in the same process? The official answer is that it is not supported and untested and therefore there are no guarantees.

This invites questions regarding scenarios that people have made work over the past several years. Precise definitions for what users can expect for any of the infinite scenarios involving .NET Framework and .NET Core 3.x/.NET 5+ are impossible so unfortunately the guidance comes down to the following – your mileage may vary but there are known scenarios where it will not work and we reserve the right to fix or close issues as "by-design". We are endeavoring to make transitioning from .NET Framework to .NET 5+ as easy as possible and if that is possible it is strongly recommended since the platform evolution is entirely focused on .NET 5+.

If there is new technical information about limitations in the scenario with .NET Core/.NET 5+ and .NET Framework in the same process, maybe you can expand a bit.

There are no new technical details or limitations. The only change that should be inferred from this statement is around how we see platform evolution and expectations on the scenario. Since the side-by-side scenario is untested and not on our current roadmap we are simply providing a clear message on what can be expected at present.

/cc @richlander

[govert]

@AaronRobinsonMSFT Thank you for the reply.

OK - I'll understand the current .NET Framework + .NET 5+ side-by-side behaviour as 'not-tested and not-by-design'. For me it seems to work fine so far, but if I run into some weird and unexpected GC or JIT clash I will squeal but not expect my money back ;-)

I would then like to add a +1 to the suggestion in this thread, that it should be a supported scenario (in your sense, and with limitation as currently known) for a future .NET 5+ version. The debugging etc. limitations are not serious, and even the issue of multiple .NET 5+ versions at once will be an issue that might be kicked down the road a bit. For now I'm likely to strongly advocate to my library users to only target .NET 6 for this scenario, so that we at least have the LTS window without much conflict.

We are endeavoring to make transitioning from .NET Framework to .NET 5+ as easy as possible [...]

A process that may already host .NET Framework independently (and will for the foreseeable long future) is one 'environment' where users might like to transition their extension components, libraries or add-ins to .NET 5+. A lot of the work you've done on native exports (UnmanagedCallersOnly etc) and COM components address these scenarios, but a clear message of support would assist our endeavors to enable a transition further.

[michaelcheers]

Just posting this in case anyone else was trying to integrate interop libraries into .NET Core and came across this issue. Since it seems like getting .NET Framework and .NET Core to work in the same process at the moment is reserved more for technical demonstrations than for production use, we need a workaround. In my own project, I was trying to get the conversion of a Word file to a PDF file to work in my ASP.NET core project. What I ended up doing was creating a separate .NET framework project which I called WordtoPDF.exe and calling it from my code.

[JoshTefay]

I see this recently published blog article describes how Microsoft’s own developers are struggling with this issue: https://devblogs.microsoft.com/dotnet/state-of-the-windows-forms-designer-for-net-applications/

It describes what is essentially a workaround. Clearly this scenario is not an edge case and is a significant impediment to .NET Framework -> .NET Core migration.

Perhaps it should be given further consideration for inclusion in .NET 7?

If the CoreCLR team has no interest in addressing this issue then maybe consideration should be given to publishing out-of-process hosting guidance and libraries to formalise the workaround the WinForms team has implemented?

[govert]

@JoshTefay Have you run into any unexpected problems when running .NET Framework and .NET 6.0 in the same process?

Apart from the known constraints listed above (assemblies are not shared, and debugging limitations), I would be interested in gathering any information or issues people run into.

In my limited testing so far it seems to work fine, and it is a scenario I plan to support for my Excel add-in library.

[JoshTefay]

@govert the primary concern is with the following statements by @AaronRobinsonMSFT above:

The official answer is that it is not supported and untested and therefore there are no guarantees.

the side-by-side scenario is untested and not on our current roadmap

It really makes it a non-starter because if Microsoft doesn't support it then we can't use it in software that our customers expect us to support.

We are endeavoring to make transitioning from .NET Framework to .NET 5+ as easy as possible and if that is possible it is strongly recommended

Addressing this issue would not only make transitioning from .NET Framework to .NET 6.0 easy, it would also make it possible for us.

[Misiu]

@govert take a look at this issue: https://github.com/dotnet/runtime/discussions/64942 and related one: https://github.com/Tyrrrz/DotnetRuntimeBootstrapper/issues/27

[robertmuehsig]

In my limited testing so far it seems to work fine, and it is a scenario I plan to support for my Excel add-in library.

@govert Do you have a sample somewhere with a .NET Core addin running inside Excel?

[govert]

@robertmuehsig Most of the Excel-DNA samples here compile and will run for both .NET Framework and .NET 6: https://github.com/Excel-DNA/Samples If you try, maybe start with the 'Ribbon' sample - https://github.com/Excel-DNA/Samples/tree/master/Ribbon

There are quite a few Excel-DNA users that have moved to .NET 6. We're also testing under newer .NET 8 - but then need to be aware of the fact that .NET 6 and .NET 8 cannot run side-by-side (although each can run side-by-side with .NET Framework without problems.)