out-of-proc COM feature in Core 3.x missing

[dougie1970]

@DoCode I am a big fan of out-of-proc COM, has some performance concerns but addresses many issues. As far as setting up an activatable COM server in a .NET Core application, that is probably possible but will require working with the hosting API and having a good understanding of authoring a COM server in general. It may also require some additional work if the interfaces aren't defined in MIDL because TlbExp doesn't exist for .NET Core. In order to consume the interfaces in a non-managed environment, headers or a TLB and proxy/stubs would need to be created and registered.

There is also the slightly cheaper way to get to an out-of-proc COM scenario using the Running Object Table. A managed example using .NET Framework is here.

The above aside, the build issue being faced in this scenario involves building a COM server class library, not a standalone application. A .NET Core application - not library - exposing a COM server should build in a self-contained manner, however that scenario hasn't been tested in .NET Core - see the COM-activation design documentation for .NET Core.

Originally posted by @AaronRobinsonMSFT in #870 (comment)

[dougie1970]

@AaronRobinsonMSFT - how does this feature for out-of-proc COM get completed and into a Core 3.x version? It would be really nice to have this same feature as it works in Framework, where regasm.exe (or similar/new command), would register a .NET Core 3.x executable. Without this capability, it would be essentially losing a nice to have feature in existing software to port it to .NET Core. I assume @DoCode would need this also.

[AaronRobinsonMSFT]

how does this feature for out-of-proc COM get completed and into a Core 3.x version?

@dougie1970 It comes down to priorities and customer demand. Right now we have some interest but not enough compared to other feature request in interop. Adding first class support would be a non-trivial amount of work and there would be some very sharp edges to fix up. Adding this for Core 3.x isn't something that is going to happen to be honest. The amount of feature work to enable this would not make it past our servicing bar.

It is possible for future runtime versions and that is tracked by #38814. Adding your scenario to that issue would help us to keep track of customer need and goals. Let's continue the conversation there.