Regression: Out arguments in many COM interfaces (eg. DXGI/D3D11) are suddenly unmanaged

[VentuzTammoHinrichs]

Actual behavior

COM Out arguments in methods in the Graphics.DXGI and .D3D11 namespaces are now I..._unmanaged** (instead of out I... in 0.3.49beta). Look at e.g. all the Create* functions in ID3D11Device.

Note that this doesn't apply to top level functions such as D3D11CreateDevice. Those still work as expected.

Expected behavior

I'd really like to have the managed out arguments back if possible.

Repro steps

1. NativeMethods.txt content:

Windows.Win32.Graphics.Direct3D11
Windows.Win32.Graphics.DXGI
D3DCompile

2. NativeMethods.json content (if present):

{
  "$schema": "https://aka.ms/CsWin32.schema.json",
  "useSafeHandles": false,
  "allowMarshaling": true
}

Context

CsWin32 version: 0.3.106
Target Framework: net8.0

[AArnott]

I suspect this change is a fallout of improving support in other areas where we discovered certain interop rules had to be honored, and this was an area where we weren't fully following the rules, causing failures in at least some cases.

I'll leave this active till we have a chance to confirm.

[FullstackSensei]

having the same issue with D3D11 after updating from 0.3.49-beta to 0.3.106

[smourier]

Same for me. It's actually a showstopper for upgrading nuget packages.

[AffluentOwl]

It wasn't that hard to work around this issue. Just had to spend the month learning x64 ASM and how to reverse engineer Windows binaries. Then produced the following elegant and idiomatic C# code which is required to both retain managed and unmanaged copies of the same COM objects, and properly handle both of their lifetimes. My new favorite part of coding in C# with projections is all the time one gets to spend reading and writing assembly.

  [Guid("94D99BDB-F1F8-4AB0-B236-7DA0170EDAB1"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown), ComImport()]
  internal interface IDXGISwapChain3Extra : IDXGISwapChain3
  {
    void _VtblGap_6();
  
    unsafe void GetBufferRaw(uint Buffer, Guid* riid, void** ppSurface);
  }

  List<ID3D12Resource> gSurfaces = new List<ID3D12Resource>();
  List<nint> gSurfacesRaw = new List<nint>();

  // ...

  guid = typeof(ID3D12Resource).GUID;
  void* ppSurface;
  gSwapChain.GetBufferRaw(i, &guid, &ppSurface);
  gSurfacesRaw.Add((nint)ppSurface);
  gSurfaces.Add((ID3D12Resource)Marshal.GetObjectForIUnknown((nint)ppSurface));
  
  gDevice.CreateRenderTargetView(gSurfaces.Last(), null, rtvHandle);
  
  // ...
  
  ID3D12Resource_unmanaged* p = (ID3D12Resource_unmanaged*)gSurfacesRaw[(int)gFrameIndex];
  D3D12_RESOURCE_BARRIER[] b = [
    new() {
      Flags = D3D12_RESOURCE_BARRIER_FLAG_NONE,
      Anonymous = new()
      {
        Transition = new()
        {
          pResource = p,
          Subresource = D3D12_RESOURCE_BARRIER_ALL_SUBRESOURCES,
          StateBefore = D3D12_RESOURCE_STATE_PRESENT,
          StateAfter = D3D12_RESOURCE_STATE_RENDER_TARGET,
        }
      }
    }
  ];
  gCommandList.ResourceBarrier(1, b);
  
  // ...

  void ResizeBuffers(nint lParam)
  {
    if (gSwapChain != null && gFence != null && gSurfaces.Count > 0)
    {
      WaitForPreviousFrame();

      for (int i = 0; i < 2; i++)
      {
        Marshal.ReleaseComObject(gSurfaces[i]);
        ((ID3D12Resource_unmanaged*)gSurfacesRaw[(int)i])->Release();
      }
      gSurfaces.Clear();
      gSurfacesRaw.Clear();

      // ...
      
      Guid guid = typeof(ID3D12Resource).GUID;
      void* ppSurface;
      gSwapChain!.GetBufferRaw(i, &guid, &ppSurface);
      gSurfacesRaw.Add((nint)ppSurface);
      gSurfaces.Add((ID3D12Resource)Marshal.GetObjectForIUnknown((nint)ppSurface));

      gDevice.CreateRenderTargetView(gSurfaces.Last(), null, rtvHandle);

[mitchcapper]

@AffluentOwl if you can update the title to just says something like "regression/breaking change: Multiple prior COM out objects are now _unmanaged double pointers" as it goes beyond the DX items. This only happened in the latest release 106 the 0.3.49 beta did not.

As this is expected it seems mostly just a few more lines of code, although one does need to track and cleanup the pointer as well now I believe. Here is a define around the old and new code.

            var FilePath=@"c:\users\image.jpg";
            PInvoke.CoCreateInstance<IThumbnailCache>(CLSID_LocalThumbnailCache, null, Windows.Win32.System.Com.CLSCTX.CLSCTX_INPROC_HANDLER | Windows.Win32.System.Com.CLSCTX.CLSCTX_INPROC_SERVER, out var thumCache);
            IShellItem shellItem = GetShellItem(FilePath);
            var size = 256u;
#if NEW_CSWIN32
            ISharedBitmap_unmanaged* img;
            thumCache.GetThumbnail(shellItem, size, WTS_FLAGS.WTS_INCACHEONLY,&img);
            img->GetSharedBitmap(out var hBitmap);           
#else
            thumCache.GetThumbnail(shellItem, size, WTS_FLAGS.WTS_INCACHEONLY,out var img);
            img.GetSharedBitmap(out var hBitmap);
#endif

[VentuzTammoHinrichs]

It was me. Changed the title.

And I also would like to bump this issue. Yes, you can work with the unmanaged pointers somehow but it's so cumbersome I'd rather write a C++ wrapper DLL now instead of using CsWin32, which kind of runs counter to its point.

[jimm98y]

Is there a mode switch that would toggle in between the old and new behavior? Starting with version 0.3.106 there are some functions that have incorrect signature, possibly as a result of this change: #1229

[jevansaks]

I believe this PR is what changed the behavior: #1109

As an enhancement on top of the PR I've got out (#1511), I can look into making a follow-up PR to improve the friendly overloads of out/ref parameters which are managed types. I'll also think about if there is a way to improve the ABI signature on the COM methods so that implementing these is not so onerous.

[jimm98y]

Yes, switching to pointers will be tedious, but when I finally decided to do it so that I can move from the beta to the latest release of CsWin32, I found out that I can't because of that broken MFTEnumEx function. I suppose this will not be the only function with this problem if the metadata are correct.

That was the main reason why I was asking about a way to switch to the old behavior, hoping it would also fix the function import.

Now I only have 2 options: keep using the 0.3.49 beta version, or write my own imports manually and stop using CsWin32.

[jevansaks]

Yeah ...the friendly methods just mis-handle basically any pointer-to-pointer types at the moment.

[mitchcapper]

Not quite as set and forget but https://github.com/mono/CppSharp I have had some good luck with and has a higher level of customization. I am not sure if I am missing something but It would seem the CsWin32 could do overloads with the old style and still provide the pointer option for those desiring to go that route, there isn't a reason it couldn't be an option too as CSWin32 just does on some other things.

[mitchcapper]

Yeah ...the friendly methods just mis-handle basically any pointer-to-pointer types at the moment.

Doesn't doing [In, Out] parameter attributes for the native signature allow for some pointer to pointer types to properly work?