Why does the COM registration generated by the AOT fail, and how do I generate it correctly?

[vitash]

When AOT is not used, the following code can register DLLs and perform COM interoperability:

[ComVisible(true), Guid("D9BF17DA-DE62-4932-8DAC-14AC6ADBE849")]
public interface IA1 {
    int Rnd1();
}

[ComVisible(true), Guid("6047C4FD-1F3A-4E8B-B640-DA44C9D0C761"), ClassInterface(ClassInterfaceType.None)]
public  class Lib1 : IA1 {
    public int Rnd1() => Random.Shared.Next();
}

When I add the last three lines, using regsvr32 xxx.comhost.dll will report errors.
(The module "xxx.comhost.dll" was loaded but the call to DllRegisterServer failed with error code 0x80008093)

    <TargetFramework>net8.0-windows</TargetFramework>
    <Nullable>enable</Nullable>
	  
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <EnableComHosting>true</EnableComHosting>

    <IsAotCompatible>True</IsAotCompatible>
    <PublishAot>true</PublishAot>
    <OptimizationPreference>Size</OptimizationPreference>

pubxml:

    <TargetFramework>net8.0-windows</TargetFramework>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <SelfContained>false</SelfContained>
    <PublishSingleFile>false</PublishSingleFile>
    <PublishReadyToRun>false</PublishReadyToRun>

How do I correctly generate an AOT COM?

[vitash]

I probably see the point of this whole thing. COM doesn't support SelfContained, then it needs Dotnet Runtime. then AOT doesn't make much sense, even if AOT's DLL is bigger.

[reflectronic]

EnableComHosting does not work with Native AOT. The Xxx.comhost.dll it generates is only designed to work with CoreCLR. I think the SDK should emit an error when EnableComHosting is combined with PublishAot.

It is still possible to write a COM server with Native AOT, but you will have to write the server code manually by implementing IClassFactory, exporting DllRegisterServer, etc. like described in COM Server Responsibilities. You will also have to switch your interop to ComWrappers source generation and away from ComImport (which does not work with Native AOT).

@AaronRobinsonMSFT @jkoritzinsky

[AaronRobinsonMSFT]

I think the SDK should emit an error when EnableComHosting is combined with PublishAot.

I'm not against this, but I'm unclear on the native AOT policy for warning on the full matrix of supported scenarios - MSBuild warnigns are hard. @agocke or @jkoritzinsky Does it make sense to try and warn for this scenario? I'd argue that if ComImport is discovered by native AOT it should warn and avoid the MSBuild side of things, but that is just me.

[jkoritzinsky]

I think it makes sense to warn when PublishAot and EnableComHosting are set.

[agocke]

Our rule is that if something is not aot compatible, you should get a warning somewhere. It’s not clear to me exactly where the warning should be — usually we try to tie the warning to some specific piece of code, and then warn when that code is present in the app. But if the bad interaction is purely in native code, an SDK warning makes sense to me

[MichalStrehovsky]

For the above snippet there already is a warning generated by the SDK that the top post chose not to mention: "warning NETSDK1128: COM hosting does not support self-contained deployments.". AOT is always self-contained. We can't do much if the users don't read warnings. We could make it an error.

[Veritera]

This comment is so underrated. It helped me solving my problem, thanks! ❤️