Fix Validation SG for Blazor Wasm SDK projects

[oroztocil]

The PR solves two issues that prevent the new validation from working in Blazor Wasm SDK projects:

• The Microsoft.Extensions.Validation NuGet package needs to include the source generator, so that it is available in Blazor Wasm SDK projects (which are not based on the ASP.NET Core runtime pack, unlike the Web SDK projects).
• The various checks for "well-known types" throw when the types are not found in the assemblies (e.g. Microsoft.AspNetCore.Http.Abstractions is not present in Blazor Wasm SDK projects). To avoid the need to refactor larger portion of the existing code, the PR solves this by returning a type symbol for a dummy type instead of throwing. This type symbol is then used in place of the missing types and comparisons against it always return false, thus providing the same outer behavior.
  • Idea: We could differentiate between "required" well-known types for which we would throw if not present in the compiled assemblies, and "optional" well-known types for which we would use this trick with a dummy type, or something functionally equivalent.

Fixes #63670

[Copilot]

Pull Request Overview

This PR fixes validation source generator support for Blazor WebAssembly SDK projects by ensuring the generator is packaged with the NuGet package and handling missing well-known types gracefully. The changes allow the validation functionality to work in environments where certain ASP.NET Core assemblies are not available.

• Package the validation source generator in the NuGet package for Blazor WASM compatibility
• Replace exception throwing with dummy type symbols for missing well-known types
• Introduce a fallback mechanism using MissingType when assemblies are not present

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/Validation/src/Microsoft.Extensions.Validation.csproj	Adds project reference and packaging configuration to include the validation source generator in the NuGet package
src/Shared/RoslynUtils/WellKnownTypes.cs	Replaces exception throwing with dummy type symbol fallback when well-known types cannot be resolved

[captainsafia]

I wonder if we should consider reusing SpecialType.None as the fallback in this case as Roslyn does in their WellKnownType implementation (ref). That let's us reuse an existing concept instead of defining out own marker type.

[oroztocil]

Compilation.GetSpecialType throws out-of-range exception if you try to resolve INamedTypeSymbol for SpecialType.None. The way CodeAnalysis.WellKnownTypes is set up in Roslyn, there is no actual type symbol associated with an unknown type. So if I am not overlooking something, we can't use it as a marker type for our purposes.

[oroztocil]

/backport to release/10.0

[github-actions]

Started backporting to release/10.0: https://github.com/dotnet/aspnetcore/actions/runs/17827846351

[captainsafia]

LGTM! The WellKnownTypes are shared across all our analyzers.

I imagine the material impact here is that scenarios that previously threw exceptions/gold-barred will now fail silently assuming the logic where the symbol comparisons happen is sane.

Some smoke testing on our framework analyzers should give us confidence here.

[oroztocil]

Based on offline discussion with @captainsafia I updated the PR so that other analyzers are not affected by the change in type symbol retrieval logic.

I added the WellKnownTypes.GetOptional method that does not throw for missing types but returns the symbol for a special marker type. This is used by the Validation generator where needed to ensure compatibility with the Blazor Wasm SDK.

The existing WellKnownTypes.Get method keeps the same throwing behavior as before.

[oroztocil]

/backport to release/10.0

[github-actions]

Started backporting to release/10.0: https://github.com/dotnet/aspnetcore/actions/runs/17852955682

[github-actions]

@oroztocil backporting to "release/10.0" failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch

Applying: Proof-of-concept fix for getting validation SG to work in Blazor Wasm SDK projects
Using index info to reconstruct a base tree...
M	src/Shared/RoslynUtils/SymbolExtensions.cs
M	src/Shared/RoslynUtils/WellKnownTypes.cs
M	src/Validation/gen/Extensions/ITypeSymbolExtensions.cs
M	src/Validation/src/Microsoft.Extensions.Validation.csproj
Falling back to patching base and 3-way merge...
Auto-merging src/Shared/RoslynUtils/SymbolExtensions.cs
Auto-merging src/Shared/RoslynUtils/WellKnownTypes.cs
CONFLICT (content): Merge conflict in src/Shared/RoslynUtils/WellKnownTypes.cs
Auto-merging src/Validation/gen/Extensions/ITypeSymbolExtensions.cs
Auto-merging src/Validation/src/Microsoft.Extensions.Validation.csproj
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0001 Proof-of-concept fix for getting validation SG to work in Blazor Wasm SDK projects
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!