I don't know if this has come up before, if that's the case i am sorry, but searching didn't yield any results.

We are currently trying to migrate from .NET 4.8 to .NET 6.0 and have hit a major road block with our usage of COM interop.

Architecture:

• C++ with lots of classes exposed via COM (this hosts our own ORM and large parts of our business logic)
• .NET (C# and WPF) GUI layer, business logic, configuration etc.

Problem case:

• Application is in .NET
• Calls into C++ via COM interop
• C++ calls into C# via COM interop
• The C# code references an interop assembly generated from a C++ tlb

Issue:
In .NET 4.8 everything works fine.
In .NET 6.0 we get type clashes (InvalidCastException for class originating from the generated interop assembly) as the .NET COMHost/ComActivator creates a separate AssemblyLoadContext, which in turn again loads the C++ interop assemblies.

I wasn't able to create a sample application, but the documentation for AssemblyLoadContext states that exactly these kinds of issues might happen if the same assemblies are loaded in different contexts.

What i would like to propose:

• Extend hostfxr to be able to create delegates for an existing context and/or allow it to return the context handle for the currently active context
• Extend comhost to allow users to specify if they want their components to be loaded in an isolated context or not (this might be transportable through the clsidmap or something new
• Extend ComActivator to allow the same as comhost would

The most important part however would be to allow ComActivator to work without AssemblyLoadContext, if a certain component requires/requests so. This would be enough to fix the issue we are experiencing.

I am not sure how to proceed from here, so i will just wait for someone to comment on this issue. ;-)

Tagging @AaronRobinsonMSFT as you seem to have added the ALC code back in 2019.