Igor Velikorossov

_Personal opinion_: I like how we have separation per containing dll (i.e., Interop.User32, Interop.Gdi32, etc). It'd be great to retain the separation if possible, e.g., /User32/NativeMethods.txt, /Gdi32/NativeMethods.txt, /Kernel32/NativeMethods.txt, etc.

> AFAIK, each NativeMethods.txt file needs to be in its own folder and added to additionalfiles. So in the context of winforms, we can place a NativeMethods.txt in each library...

@AArnott if I read it correctly, the CsWin32 guideline is to commit to a specific bitness, which may work for a end-user app but doesn't work for for an SDK...

We don't package or release directly, and our binaries follow an established flow through several layers (dotnet/winforms->dotnet/wpf->dotnet/windowsdesktop->...). So we can't target specific bitness, as it would require us to completely...

This is a Windows issue, a pure MFC app will look the same.

If you have a fix in mind, please feel free to open a draft PR to continue the discussion.

It is building on the CI as well, but looks like a VB related test `Microsoft.VisualBasic.Logging.Tests.LogTests.Write` is failing: ``` Error message System.NullReferenceException : Object reference not set to an instance...

Since `nint`/`nuint` are aliases I see no issues updating our APIs to match. Also I don't necessarily think the changes need to be recorded as "unshipped" since we aren't technically...

We need to revert https://github.com/dotnet/winforms/pull/2869

I don't think this is feasible - the API surface is different, the types are different, the deployment model is different... It sounds similar to "I want to continue building...