Is it not possible to load two C# COM object built with different NETCore versions?-CodePudding

I have a legacy system written in Delphi that needs to consume COM objects built in NETCore. Everything was working fine while all COM assemblies were built with NET6. The problem began when I tried to load a new COM object written in NET7. That is the error I get:

The specified framework 'Microsoft.NETCore.App', version '6.0.0', apply_patches=1, version_compatibility_range=minor is incompatible with the previously loaded version '7.0.1'.

In Delphi I'm using the CreateComObject function from System.Win.ComObj to get the COM.

In C# I'm using ComVisible(true), and I'm also generating a MyCSharpCom.comhost.dll and using regsvr32 to registry it.

My question is: why is the load of one COM object sharing the same NET framework with the others ones?

Is it possible to fix that keeping the same architecture, since I cannot enforce the NET core version used by third parties who also write COM objects as a plugin/extension to be consumed by a Delphi exe?

CodePudding user response：

There can only be a single instance of the .NET runtime loaded at a time in any given process. The load fails because you are using the COM classes in process and they try to load multiple instances of the .NET runtime to the same process.

You would need to use the COM classes out of process.

If the supplier of the COM classes is not able to give you out of process version of the COM class then you would need to create separate out of process COM server applications using .Net which would act as a proxy to the the in process COM classes. You may decide to only create a proxy for the .Net 7 COM classes, so .net 6 COM classes would be continued to used as it is but the .Net 7 would be used via the proxy out of process. Or you may create proxies for all classes, depending on your needs.

Here is an example how to create out of process COM class in .Net: https://github.com/dotnet/samples/tree/main/core/extensions/OutOfProcCOM

CodePudding user response：

I believed COM objects ran in separated execution spaces, regardless of the language and framework used they shouldn't mess with each other. Maybe there's an optimization in .Net that forces one framework per application, possibly it can be disabled.