Regression in 0.1.560-beta CS0436/CS0103 due to type conflict

[AliveDevil]

Actual behavior

I cannot use the simple type-name "PInvoke" in any project-structure that requires CSWin32 in multiple locations, and am forced to use verbose names like SharedPInvoke, AppPInvoke etc. to circumvent this issue.

I cannot use any Constant in a project structure that requires CSWin32 in multiple locations, as I am unable to override the Constants class-name rendering it unusable.

Expected behavior

Either of:
I'm allowed to set a custom namespace again (partially reverting bf59af5)
Adding schema extension "importedNamespaces", which allows type reuse with static aliases (using constants2 = ImportedNamespace2.Constants)
Makes finding already imported (referenced) more difficult for the SourceGenerator.

Allow override Constants-class name
Allows for duplicate constants to be imported.

Repro steps

Added a sample project consisting of three projects: one shared, and two not-related apps, sharing the PInvoke.
Real world scenario for me:

• Shared and App1 are in the same solution
• App2 has a dll-reference to Shared - but not App1 - through some dependency management framework (not NuGet)

some-project.zip

I can use LVM_FIRST in app2, but not in app1. I expect this to work in app1 as well.
I can use LVM_SCROLL in app1.

Context

• CsWin32 version: 0.1.560-beta
• Target Framework: net47 and net5.0-*

[AliveDevil]

Comment, as it's my personal opinion which does not belong in to the issue itself:

I'd rather have Allow override Constants-class name than being able to set custom namespaces, as I'm really in to the types being shared between PInvoke projects. Used the namespaces for separation before and it really is a pain to maintain, especially with those duplicate types.

[AArnott]

I share your preference for the ability to control the name of the Constants class.

Till this is resolved, a workaround is to add an alias to your P2P reference, which would allow you in C# to distinguish between the two imported types with the same full names.

[AliveDevil]

Ah features noone is aware of.
This does make working with same names easier, thats true. I'll check the alias-route and wait patiently for native support here.

[AArnott]

Another option is to generate constants under the same class as the methods. I think that would clutter things too much for larger projects, but I'm interested in feedback.

[AliveDevil]

Speaking for this approach would be the nature of the underlying APIs: importing a header imports everything into global namespace, thus making it available everywhere. Having one static import for generated code could be an option, generating all constants in a single source generator file (Windows.Win32.Constants.cs, which just renders into ClassName), making it easy to find just as the Constants-class.

Wonder what the IntelliSense-implications are here … couldn't be much worse than IntelliSense in C(++)-projects I guess.