[release/8.0-staging] Use fully qualified names when referencing user types. (#94267)

[eiriktsarpalis]

Backport of #94267 to release/8.0-staging

Customer Impact

As implemented, the ConfigurationBinder source generator employs using statements to import namespaces of user-defined types and references these types by name only. This can cause compiler errors in cases where there is ambiguity -- i.e. referencing types with equal names but in different namespaces. This is blocking partner teams when working with common scenaria, see #93498.

This PR updates the source generator to always use fully qualified names when referencing user declared types.

Testing

Added regression testing covering the type name conflict scenario. Manually tested eshopOnContainers sample, and Azure.Data.Tables package as well.

Risk

Low to moderate. Makes substantial changes to product code, replacing all type formatting from minimal to fully qualified names.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #94267 to release/8.0

Customer Impact

As implemented, the ConfigurationBinder source generator employs using statements to import namespaces of user-defined types and references these types by name only. This can cause compiler errors in cases where there is ambiguity -- i.e. referencing types with equal names but in different namespaces. This is blocking partner teams when working with common scenaria, see #93498.

This PR updates the source generator to always use fully qualified names when referencing user declared types.

Testing

Added regression testing covering the type name conflict scenario.

Risk

Low to moderate. Makes substantial changes to product code, replacing all type formatting from minimal to fully qualified names.

Author:	eiriktsarpalis
Assignees:	eiriktsarpalis
Labels:	area-Extensions-Configuration
Milestone:	-

[teo-tsirpanis]

Should this target release/8.0-staged?

[tarekgh]

oops, @teo-tsirpanis is correct. This should be ported to release/8.0-staged instead. good catch.

[ericstj]

I went ahead and changed the target branch of the PR. It should port cleanly as we haven't had churn there.

edit: looks like we need to remove a couple commits.

[danmoseley]

is it possible to check our various other source generators in the box for the same issue?

[eiriktsarpalis]

is it possible to check our various other source generators in the box for the same issue?

STJ has been using fully qualified names since it shipped. Not sure what the case is with options validator or the logger cc @tarekgh

[tarekgh]

Logging and options source generators use fully qualified names too. You may look at examples here:

https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.Extensions.Logging.Abstractions/tests/Microsoft.Extensions.Logging.Generators.Tests/Baselines/TestWithDefaultValues.generated.txt
https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.Extensions.Options/tests/SourceGenerationTests/Baselines/NetCoreApp/Validators.g.cs

[danmoseley]

Yeah and the Regex one and the RequestDelegateGenerator do as well, but how to figure whether they're using global:: in all necessary places, not sure. I assume so :) @captainsafia

[danmoseley]

@BrennanConroy what about the SignalR generators?

[BrennanConroy]

@BrennanConroy what about the SignalR generators?

It's not shipping. But if we have validation that can be added we'd be interested so we can add it when we do want to ship it.

[captainsafia]

Yeah and the Regex one and the RequestDelegateGenerator do as well, but how to figure whether they're using global:: in all necessary places, not sure. I assume so :) @captainsafia

RDG uses FQN + global:: for all user provided types. The display format we use is defined here.

[ericstj]

Approved over mail.