Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Answered by reflectronic
vitash asked this question in Q&A
Discussion options

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?

You must be logged in to vote

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

Replies: 2 comments 5 replies

Comment options

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.

You must be logged in to vote
0 replies
Comment options

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

You must be logged in to vote
5 replies
Comment options

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.

Comment options

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

Comment options

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

Comment options

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.

Comment options

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

Answer selected by AaronRobinsonMSFT
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

AltStyle によって変換されたページ (->オリジナル) /