Why you still can't create self-contained COM deployments with .Net

[ekalchev]

Why you still can't create COM component in C# with self-contained deployment?

here link to documentation that says it is not possible https://learn.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com

[Self-contained deployments](https://learn.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained) of COM components are not supported. Only [framework-dependent deployments](https://learn.microsoft.com/en-us/dotnet/core/deploying/#publish-framework-dependent) of COM components are supported.

So ppl using MSIX package to deploy their apps - which is supposed to be the future of windows installation, microsoft doesn't give an option to install a framework package for .Net. As a workaround they suggest to use self-contained deployments - there is no way around that - you basically forced to use dotnet self-contained deployment if you choose MSIX.

If you do that you are not allowed to use COM components written in .NET because they are not supported by self-contained deployments. What is the reason for this limitation and is this going to be resolved ever?

[czdietrich]

This limitation is also very problematic for us.
.NET (Core) introduced self-contained builds as a way to support deploying apps without being dependent on the installation of any framework on the target machine. So we adopted this way of deploying apps and now realizing that it does not work for assemblies that integrate into the Windows shell using COM.

So unfortunately, we are at a point where we either drop such feature in general, only support it for customers that have the correct .NET runtime installed by their own or have an additional installer that installs the needed runtime(s) only for that feature in parallel to the still self-contained .NET apps we provide.

[ekalchev]

Nobody is paying attention to this problem. There are multiple issues for that over the years. I don't think they even want to find a solution for that. Workaround is to use C++ to write the COM components. (or port your code to GoLang lol)

[teo-tsirpanis]

I'm not sure why COM hosting with self-contained deployments is not supported, but I can imagine that it is to prevent loading multiple .NET runtimes in the same process. Distributing the .NET runtime in an MSIX package is tracked in #51574.

Maybe you could use Native AOT to create a self-contained COM host, but I am not familiar with COM hosting and don't know if it will work or what the complications would be.

[AaronRobinsonMSFT]

@ekalchev @czdietrich Sorry this is blocking you. I'll update the documentation with justification. @teo-tsirpanis is correct here. The issue is about accidentally loading multiple .NET runtimes into the same process with little recourse on behalf of the COM client. Deploying self-contained was explicitly blocked to avoid distribution of COM servers that could negatively impact the system and leak to unexpected behavior around the ordering COM server activation.

As an alternative, writing your .NET COM in native AOT would avoid this issue. There is no obvious blocking problem here, although you would need to expose the appropriate COM entry points and IClassFactory for the COM servers. It is possible there are other issues with native AOT, but most if not all should be easy to mitigate in practice.

[AustinWise]

There is a sample showing how to use NativeAot to create a COM server:

https://github.com/dotnet/samples/tree/main/core/interop/source-generation/ComWrappersGeneration