GeneratedComInterface

[catmanjan]

I'm looking at native AOT and one of the things it requires is interfaces being labelled GeneratedComInterface

https://learn.microsoft.com/en-us/dotnet/standard/native-interop/comwrappers-source-generation

I need to check, but I think simply adding this attribute everywhere appropriate will just work?

[catmanjan]

I've started doing this to my own copies of the classes and visual studio has suggested just replacing every instance of ComImport with GeneratedComInterface

[catmanjan]

After doing some more research it looks like there may be a lot more work to do for Vanara to be Native AOT compatible, is this something on the roadmap?

[dahall]

See #261

[catmanjan]

Thanks, I think for our purposes replacing ComImport with GeneratedComInterface would get us 99% of the way there

For now it sounds like we will have to swap back to cswin32 for aot support

[dahall]

Given that the library cannot support AOT, what is value of adding GeneratedComInterface? I cannot find anything.

[catmanjan]

@dahall in my scenario, I am creating COM classes which implement Vanara COM interfaces, e.g. IExplorerCommand

Because I want to do NativeAOT (ComWrapper) I need to decorate my class with [GeneratedComClass], but this requires the interface to also be decorated with [GeneratedComInterface]

I don't think there is any side effect of adding this attribute

Also, regarding the library not supporting AOT - I've nearly got a fully working cloudfilter (cfapi.h) project using Vanara and NativeAOT - in fact the only change I had to make for Vanara support to work was to precompute some struct sizes with Marshal.SizeOf<CF_*> calls - it seems that this was enough for the compiler to detect which structs needed to be bundled into the project

[dahall]

Thank you. I see the advantage now but have two impediments:

1. Converting to GeneratedComInterface will only work for .NET 8 and later. This project support runtimes back to 4.8. I don't see a way to get around this, especially if done with the next impediment.
2. All GeneratedComInterface interfaces respect inheritance whereas in ComImport requires false inheritance by reimplementing all inherited methods with the new modifier. There are hundreds of interfaces that need to be changed. This one is doable, it will just take a lot of work.

[catmanjan]

Yep I understand... anyway I'm happy with the solution I have now - I use Vanara for outgoing COM communication (cfapi.h) and cswin32 for incoming COM (inproc exeserver)

[MacKey-255]

Any news?

Using ITaskService in Vanara.PInvoke.TaskSchd v5.0.4 with <PublishAot>true</PublishAot>. Throws me:

System.NotSupportedException: Built-in COM has been disabled via a feature switch. See https://aka.ms/dotnet-illink/com for more information.

[zhuxb711]

I would suggest using CsWin32 for AOT scenario instead of Vanara. However, using CsWin32 might be painful because it only support unsafe methods which means the developer must operate the pointer directly. Besides, CsWin32 would not support the undocumented COM or API. For those scenarios, declare the COM or API using GenerateCOMInterface by yourself.

[catmanjan]

Yeah I ended up swapping completely to cswin32 which I don’t love because of the lack of managed interop