AOT Support?

[smourier]

Hi,

It's not clear to me what's the status of CsWin32 (in every aspect but I'm mostly interested in generated COM interfaces) vs AOT (I'm talking .NET8 and beyond https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net8plus%2Cwindows).

Is it supported (it doesn't seem it is but ...)?
If not, will it ever be? Any timeframe/roadmap?

Thanks!

[AArnott]

Yes, we expect that AOT works with CsWin32-generated code. In fact WinForms in .NET 8 uses CsWin32 heavily.

But for AOT support, your project should include a NativeMethods.json file that sets "allowMarshaling": false. That will switch to the ComWrappers system and is trimmable/AOT friendly.

[smourier]

If I create this project (.NET 8+AOT):

<Project Sdk="Microsoft.NET.Sdk">

	<PropertyGroup>
		<OutputType>Exe</OutputType>
		<TargetFramework>net8.0</TargetFramework>
		<Nullable>enable</Nullable>
		<PublishAot>true</PublishAot>
	</PropertyGroup>

	<ItemGroup>
	  <PackageReference Include="Microsoft.Windows.CsWin32" Version="0.3.49-beta">
	    <PrivateAssets>all</PrivateAssets>
	  </PackageReference>
	</ItemGroup>

</Project>

With a NativeMethods.txt file like this:

CreateDXGIFactory
IDXGIFactory

And a Program.cs like this:

using Windows.Win32;
using Windows.Win32.Graphics.Dxgi;

namespace ConsoleApp5
{
    internal class Program
    {
        static void Main()
        {
            PInvoke.CreateDXGIFactory(typeof(IDXGIFactory).GUID, out var fac).ThrowOnFailure();
        }
    }
}

Generation and compilation works fine, but at runtime, I get this error:

Unhandled exception. System.NotSupportedException: Built-in COM has been disabled via a feature switch. See https://aka.ms/dotnet-illink/com for more information.
   at System.StubHelpers.InterfaceMarshaler.ConvertToManaged(IntPtr& ppUnk, IntPtr itfMT, IntPtr classMT, Int32 flags)
   at Windows.Win32.PInvoke.CreateDXGIFactory(Guid* riid, Object& ppFactory)
   at Windows.Win32.PInvoke.CreateDXGIFactory(Guid& riid, Object& ppFactory) in E:\ConsoleApp5\Microsoft.Windows.CsWin32\Microsoft.Windows.CsWin32.SourceGenerator\Windows.Win32.PInvoke.dxgi.dll.g.cs:line 32
   at ConsoleApp5.Program.Main() in E:\ConsoleApp5\Program.cs:line 10

And I don't see how to fix this since the generated code doesn't use ComWrappers, or am I mistaken?

[AArnott]

Add to your repro a NativeMethods.json file that sets "allowMarshaling": false. That will switch to the ComWrappers system and is trimmable/AOT friendly.

[smourier]

Ok thanks, it wasn't obvious looking at available documentation. For reference, I can have it work with this .csproj

<Project Sdk="Microsoft.NET.Sdk">

	<PropertyGroup>
		<OutputType>Exe</OutputType>
		<TargetFramework>net8.0</TargetFramework>
		<Nullable>enable</Nullable>
		<PublishAot>true</PublishAot>
		<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
	</PropertyGroup>

	<ItemGroup>
	  <None Remove="NativeMethods.json" />
	</ItemGroup>

	<ItemGroup>
	  <PackageReference Include="Microsoft.Windows.CsWin32" Version="0.3.49-beta">
	    <PrivateAssets>all</PrivateAssets>
	  </PackageReference>
	</ItemGroup>

</Project>

NativeMethods.json:

{
  "$schema": "https://aka.ms/CsWin32.schema.json",
  "allowMarshaling": false,
  "comInterop": {
    "preserveSigMethods": [ "*" ]
  }
}

And this code:

    static unsafe void Main()
    {
        PInvoke.CreateDXGIFactory(typeof(IDXGIFactory).GUID, out var obj).ThrowOnFailure();
        var factory = (IDXGIFactory*)obj;

        IDXGIAdapter* adapter;
        var i = 0;
        while (factory->EnumAdapters((uint)i, &adapter).Succeeded)
        {
            adapter->GetDesc(out var desc);
            Console.WriteLine(desc.Description));
            i++;
        }
    }

One last question: this code has now the requirement of being "fully unsafe", is there any way to make it generate IntPtr/managed interfaces instead of raw pointers? Something like this:

    static void Main() // not unsafe (csproj still has AllowUnsafeBlocks true)
    {
        PInvoke.CreateDXGIFactory(typeof(IDXGIFactory).GUID, out IntPtr unk).ThrowOnFailure();

        var cs = new StrategyBasedComWrappers();
        var factory = (IFactory)cs.GetOrCreateObjectForComInstance(unk, CreateObjectFlags.None);

        var i = 0;
        while (factory.EnumAdapters((uint)i, out var adapter).Succeeded)
        {
            adapter.GetDesc(out var desc);
            Console.WriteLine(desc.Description);
            i++;
        }
    }

[smourier]

I'm currently porting my DirectN project (https://github.com/smourier/DirectN) into a .NET 8 AOT-compatible version (https://github.com/smourier/DirectNAot), using a tool of my own (https://github.com/smourier/Win32InteropBuilder) that generates code based on newer CLR interop constructs . It's based on the win32metadata nuget, but not on CsWin32 for the reasons I gave.

In this project (work in progress), my objectives are the following:

• 100% AOT support
• Use ComWrapper source generation for COM
• Use LibraryImport for p/invoke
• Don't use unsafe C# code (obviously allow unsafe blocks for AOT support), so don't use raw pointers variables like int*, so restrict all pointers to IntPtr

Few remarks:

• I use InlineArray when needed for fixed sized buffers since it's compatible with AOT
• I use PreserveSig (HRESULT) everywhere I can for reasons above
• In this specific package, I unify all namespaces into one. All types are in this namespace, there's one file for all constants declaration, one file for all functions (LibraryImport). I think it's easier for coding instead of searching for namespaces but this is arguable :-)

The current version compiles but lacks some features the current has. Here are some examples:
COM interface https://github.com/smourier/DirectNAot/blob/main/DirectNAot/Generated/DirectN/IDXGIFactory1.cs

[SupportedOSPlatform("windows6.1")]
[GeneratedComInterface, Guid("770aae78-f26f-4dba-a829-253c83d1b387")]
public partial interface IDXGIFactory1 : IDXGIFactory
{
    [PreserveSig]
    [return: MarshalAs(UnmanagedType.Error)]
    HRESULT EnumAdapters1(uint Adapter, out IDXGIAdapter1 ppAdapter);
    
    [PreserveSig]
    [return: MarshalAs(UnmanagedType.U4)]
    bool IsCurrent();
}

Constants https://github.com/smourier/DirectNAot/blob/main/DirectNAot/Generated/DirectN/Constants.cs
Functions https://github.com/smourier/DirectNAot/blob/main/DirectNAot/Generated/DirectN/Functions.cs

Structs with fixed sized array embedded https://github.com/smourier/DirectNAot/blob/main/DirectNAot/Generated/DirectN/DXGI_OUTPUT_DESC.cs:

[StructLayout(LayoutKind.Sequential)]
public partial struct DXGI_OUTPUT_DESC
{
    public InlineArraySystemChar32 DeviceName;
    public FoundationRECT DesktopCoordinates;
    
    [MarshalAs(UnmanagedType.U4)]
    public bool AttachedToDesktop;
    public DXGI_MODE_ROTATION Rotation;
    public HMONITOR Monitor;
}

[InlineArray(32)]
public partial struct InlineArraySystemChar32
{
    public char Data;
    
    public override readonly string ToString() => ((ReadOnlySpan<char>)this).ToString();
}

BTW while building constants, I came accross the Windows.Win32.Foundation.RT_RCDATA constant which is defined as a character by win32metadata (\u000A). CsWin32 generates this code which is wrong:

internal static partial class PInvoke
{
	internal static readonly unsafe winmdroot.Foundation.PCWSTR RT_RCDATA = (char*)(10);
}

[AArnott]

Thanks for sharing.

I came accross the Windows.Win32.Foundation.RT_RCDATA constant which is defined as a character by win32metadata (\u000A). CsWin32 generates this code which is wrong:

Why is it wrong? That look like one of those constants that are special values but typed as pointers for use in APIs that consume PWSTR or PCWSTR but will specially recognize this value. You say the win32metadata defines this as a character, but it actually declares it as a PWSTR (a typed pointer) whose value is 10. I believe this is what CsWin32 is also doing. What win32metadata does isn't actually valid C# directly.

In this specific package, I unify all namespaces into one

CsWin32 used to do this too. But we were forced to honor the namespaces in the metadata when the metadata started carrying types with the same name but in different namespaces in order to avoid collisions.

[smourier]

Why is it wrong?

Opps sorry, my mistake!

About unified namespace, yes, but it's still interesting when you just want a part of the whole metadata, which is in the end quite frequent.

[whiskhub]

Is there an update regarding this? It would be nice if CsWin32 could generate AOT safe code that at the same time retains the "non-unsafe" helpers and interfaces.

In my naive understanding, wouldn't it be possible for CsWin32 to generate code that has the .NET source generator attributes applied? So for example, CsWin32 could generate such a COM interface:

[GeneratedComInterface]
[Guid("3faca0d2-e7f1-4e9c-82a6-404fd6e0aab8")]
internal partial interface IFoo
{
    void Method(int i);
}

or such a function:

[LibraryImport("user32.dll")]
internal static partial bool IsIconic(HWND hwnd);

You said something about "the compiler won't do source generator chaining for us" - does it mean that source generated code cannot be source for another source generator?
Again, I'm no expert here - I just envision the same developers experience currently available for non-AOT in AOT apps as well.

[AArnott]

You said something about "the compiler won't do source generator chaining for us" - does it mean that source generated code cannot be source for another source generator?

That's correct. So we can't simply emit [LibraryImportAttribute] and expect the other source generator to notice, because it won't.

Our plan at the moment is that CsWin32 will embed the LibraryImportAttribute source generator within itself and invoke it directly to generate the code. This will allow users to retain the more friendly APIs while still avoiding the marshaler (thus being AOT-ready). That work hasn't been scheduled though.

[mungojam]

Perhaps it would have been better for me to post this here: #1401. I'm struggling with getting the AOT/trim-safe mode working. I'm sure the end result is very simple but my lack of knowledge around COM is blocking me, and AI attempts to fix it aren't getting all the way to a working version either (maybe they are getting closer, impossible to tell)

[smourier]

This is because CsWin32 generates this (independently from the allowMarshaling value):

[Guid("A9927F85-A304-4390-8B23-A75F1C668600"),ComImport()]
internal partial class ProofOfPossessionCookieInfoManager
{
}

When allowMarshaling is set to true, the built-in .NET marshaling uses the ComImport attribute to implicitely create the COM object that has a CLSID equal to the type's Guid when you do a "new".

This magic is gone when built-in marshaling is gone (AOT cases), an object is created but it's not a COM object and it's vtable pointer is null (hence the error).

You now must create the COM object "manually". So add "CoCreateInstance" in NativeMethods.txt, and do this for example:

PInvoke.CoCreateInstance<IProofOfPossessionCookieInfoManager>(
    typeof(ProofOfPossessionCookieInfoManager).GUID, // the CLSID
    null,
    Windows.Win32.System.Com.CLSCTX.CLSCTX_ALL,
    out var provider);

[mungojam]

@smourier amazing, thank you that has worked.

I think I've got to adjust my original clean-up code, looks like just calling ->Release() on the provider pointer does the job.