search

microsoft / CsWin32

A source generator to add a user-defined set of Win32 P/Invoke methods and supporting types to a C# project.
MIT License
1.99k stars 84 forks source link

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

Closed asklar closed 3 months ago

asklar commented 3 months ago

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

AArnott commented 3 months ago

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.

asklar commented 3 months ago

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?

AArnott commented 2 months ago

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.