Closed 0x5bfa closed 1 month ago
I had a PR on my work but because of this the work was abandoned.
https://github.com/files-community/Files/pull/15793
gh pr checkout 15793
will check out to my PR in Files repo.
modifier: 'public'
isn't valid JSON. I suspect you mean "public": true
or "public": false
.
Are you using InternalsVisibleTo
anywhere? If not, the internal members of a referenced assembly shouldn't break you at all. What they can do is change a c# error from "this member doesn't exist" to "this member is inaccessible", which can make it look like there's a problem when really all you need to do is have CsWin32 declare the API locally.
It's hard for me to say anything more because you haven't actually quoted an actual compilation error. I recognize you gave me a repro that involves cloning a repo but I don't usually have time to do that, especially for large repos. If you can come up with a minimal repro that would be good.
Thanks for the reply.
Are you using InternalsVisibleTo anywhere?
No, neither do.
you haven't actually quoted an actual compilation error.
The error was CS0122 "'member' is inaccessible due to its protection level". WinUIEx defined HWND and Files.App.CsWin32 as well, then HWND had the error.
If you can come up with a minimal repro that would be good.
Unfortunately I workaround'd this by removing WinUIEx dependency. Therefore, closing as I no longer can reproduce. When I get some time, I'll let you know here.
Actual behavior
When I install WinUIEx (configures internal modifier) into my main application project and create a class project and I want to refer CsWin32 both from the app project (Files.App) and from the class project (Files.App.Server), I'd create a new class project that refers to CsWin32 (configures public modifier) (Files.App.CsWin32) and then reference it from both projects. Then because WinUIEx's generated code has internal modifier, modifier error persists while defined functions in Files.App.CsWin32 are generated as public ones.
Shortly, WinUIEx's internally generated code is respected by the C# complier, when the same definitions exist in both WinUIEx and Files.App.CsWin32 on the emitter table (NativeMethods.txt).
I literally don't have any idea how to fix on CsWin32 side, do you have?
Expected behavior
Respect publicly generate codes.
Repro steps
NativeMethods.txt
content in both WinUIEx and Files.App.CsWin32:2.a.
NativeMethods.json
content in WinUIEx:2.b.
NativeMethods.json
content in Files.App.CsWin32None
Context
LangVersion
latest