Authoring CsWinRT components with nint/IntPtr

[FreddyDgh]

Whenever I try to author a WinRT component (using CsWinRT version 1.4.1), and I have a method that uses nint or System.IntPtr in the signature, the WinRT source generator breaks. The build completes successfully, and I think the output WinMD is ok, but the implementation component does not have the generated code that it needs. This is what I see in the log file:

error: 'element type not supported: IntPtr' when processing MyLib.IMyInteropClass
 error: element type not supported: IntPtr


System.ComponentModel.Win32Exception (0x80004005): Incorrect function
   at Generator.ComponentGenerator.GenerateSources()
   at Generator.ComponentGenerator.Generate()

Is there any reason IntPtr shouldn't work in this scenario? Is there perhaps some sort of alternative, equivalent type that I need to use for WinRT? Or some attribute that need to set? I am not able to find anything in the documentation about this.

[manodasanW]

@FreddyD-GH native ints (nint) are not supported by WinRT which is why you are seeing the element type not supported error. Is there a WinRT type that you think it should map to?

I agree that the build completing successfully is misleading. Currently the Rosyln compiler treats errors in source generators as warnings and don't break the build. Hopefully that changes in the future.

[FreddyDgh]

@manodasanW Is there an easy way to inspect .winmd files? I believe Microsoft.Windows.SDK.Win32Metadata is already creating handle types that use native ints (e.g. HWND), but I'm not sure what they are mapping it to. I'm basically looking to replicate that same behavior for my own WinRT component.

[manodasanW]

@FreddyD-GH you can inspect winmds with either ildasm or ilspy. But Microsoft.Windows.SDK.Win32Metadata is a representation of the Win32 API surface which does have IntPtrs and a wider set of types. WinMDs are capable of supporting native ints which I am assuming is what they are using in Win32Metadata, but it is WinRT itself which doesn't have it as a type as per here.

What is the scenario you are looking at using native ints in?

[FreddyDgh]

@manodasanW Ahh, I understand what you are saying. The WinMD supports it, but "WinRT" doesn't. I was mainly just looking at using WinRT for an easier way of doing interop with native code, for when C# libraries exist and native ones don't. One of the primary scenarios I was trying out was using WinRT to host WPF content in a Win32 window via HwndSource (so, literally using an HWND) and being able to send data back and forth, without having to manually use the .NET hosting APIs. It actually worked fairly well (once I finally figured out that using nint was the problem), but I did end up having to use int/long in the WinRT types and cast back and forth to nint all over the place, which was getting a bit messy.