[release/8.0] Disambiguate type names by containing assembly in WellKnownTypes #52130
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #50969 to release/8.0
/cc @captainsafia
Description
ASP.NET Core's analyzer implementations use a well-known type cache to store
TypeSymbols
associated with key types in the ASP.NET Core space. The implementation of this cache currently uses Roslyn'sGetTypeByMetadataName
to resolve the type symbol from the current compilation by its name. The behavior of this API is such that it throws if it encounters two types with the same fully-qualified name in different assemblies.This has posed a problem for certain types like
IEndpointRouteBuilderExtensions
which are defined in the same namespace in both ASP.NET Core and 3rd-party packages likeAspNetCore.HealthChecksUI
andHotChocolate
.To resolve this issue, we resolve all types with a given name in the users compilation but filter by containing assemblies under the
Microsoft.*
andSystem.*
assembly names.Closes #50836
Customer Impact
When users try to build or edit projects in Visual Studio that contain references to impacted packages (like
AspNetCore.HealthChecksUI
) they will encounter unhandled exceptions. Customers can workaround this by manually disabling analyzers that ship as part of the ASP.NET Core runtime and target Minimal APIs.Regression?
Risk
This change is low-risk given that (a) the affected code does not affect app's runtime behavior and (b) existing workarounds are still viable if users run into issues with this fix.
Verification