Using cswin32 projected types in class libraries results in CS0051 Inconsistent accessibility about cswin32 HOT 3 CLOSED

They are ABI safe. But all generated APIs are internal by default so that your library doesn't leak win32 definitions just because you consume them.
If you want them to be public, there's a switch in NativeMethods.json that lets you do so. Check out our readme.

from cswin32.

thanks @AArnott. I don't want to expose all of the APIs I consume out of my package, just the HANDLE-ish types. It sounds like there is a global switch but not a per-type switch?

from cswin32.

That is correct. The type reference graph is complex and CsWin32 is quite complex itself, so at present we have no plans to allow selective visibility switches.
We think this is a good thing in the short term anyway, because your library often wants a stable public API, but CsWin32 is driven by win32metadata which is not yet stable, so it may change your public API without you realizing it if you ever upgrade the package.
I recommend you declare your own public HRESULT type. You can even copy and paste it from what CsWin32 generates. By declaring your own (in the same namespace as CsWin32 would have), CsWin32 will notice and reuse it rather than generate a conflicting type.

from cswin32.