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]

@JeremyKuhne thanks, I remember I already looked at WInterop some years ago. I know DirectX and Direct2D quite well, I’ve also worked on similar stuff (just because Microsoft doesn’t provide something like TerraFx & Winterop in an official way :-):

I have DirectN that's like TerraFx. It's more "wrappers" than a full object model but doesn't require unsafe at all and doesn't require .NET Core (supports .NET framework).
And then I have Wice over DirectN that is a UI engine based on Direct Composition and Direct2D (no Winforms, no WPF, no WinUI3, just Win32 and the DWM).

I'm now thinking about providing an AOT version of these projects and ideally, I'd like them to be based on Win32Metadata and CsWin32 (both projects didn't exist when I started DirectN) but I'd also like to avoid * pointers like the code I have today. Ideally, I’d also like to use the newer officially generated .NET Core 8 COM Wrappers.

[AArnott]

There has been a little talk about CsWin32 'chaining in' the COM source generator from the .NET SDK, since the compiler won't do it for us. But nothing we've followed up on. Getting specifics about where CsWin32's current code generation falls short and what additional code you'd like to see generated would be very helpful for when we get time to invest more in this area.

[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.