Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
asklar opened this issue Mar 16, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@asklar
Copy link
Member

asklar commented Mar 16, 2024

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]
@asklar asklar added the bug Something isn't working label Mar 16, 2024
@AArnott
Copy link
Member

AArnott commented Mar 22, 2024

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.

@AArnott AArnott closed this as not planned Won't fix, can't repro, duplicate, stale Mar 22, 2024
@asklar
Copy link
Member Author

asklar commented Mar 23, 2024

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
Copy link
Member

AArnott commented Apr 11, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants