microsoft / CsWin32

A source generator to add a user-defined set of Win32 P/Invoke methods and supporting types to a C# project.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Using cswin32 projected types in class libraries results in CS0051 Inconsistent accessibility

asklar opened this issue · comments

Actual behavior

I created a class library that has a public method that takes a cswin32 projection struct (HMONITOR).
This results in
Error CS0051 Inconsistent accessibility: parameter type 'HMONITOR' is less accessible than method 'CaptureHelper.CaptureMonitor(HMONITOR)'

Expected behavior

cswin32 HANDLE-derived types should be abi safe and can be used as parameters in class libraries

  • CsWin32 version: 0.3.49-beta
  • Win32Metadata version (if explicitly set by project):
  • Target Framework: net6.0
  • LangVersion (if explicitly set by project): [e.g. 9]

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.

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?

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.