[Bug] Metadata extraction fails with .NET 11 SDK: Razor analyzer ReferencesNewerCompiler (5.11.0 vs bundled 5.9.0)

[uo-uhbc]

Describe the bug

docfx metadata fails on the .NET 11 SDK for projects containing Blazor components that use @inherits together with a code-behind partial class override.

The Razor source generator shipped with the SDK cannot be loaded by the Roslyn version docfx bundles, so the generated partial class is never produced and every code-behind override fails with CS0115.

This is the same mechanism as #11046, which was addressed in #11124 by bumping the bundled Roslyn to 5.9.0. The .NET 11 SDK ships Roslyn 5.11.0, so the gap has reopened. Directory.Packages.props on main still pins 5.9.0 for non-net8.0/net9.0 TFMs.

Component	Roslyn version
docfx 2.80.1 (tools/net10.0)	5.9.0-1.26357.3
.NET SDK 11.0.100-rc.1.26425.128	5.11.0-1.26425.128

Since .NET 11 is close to GA, this will affect any project documenting Razor components on the new SDK.

To Reproduce

Minimal repro — a Razor class library with four files:

ReproLib/ReproLib.csproj

<Project Sdk="Microsoft.NET.Sdk.Razor">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
  </ItemGroup>
</Project>

ReproLib/ReproBase.cs

using Microsoft.AspNetCore.Components;

namespace ReproLib;

public abstract class ReproBase : ComponentBase
{
    protected virtual string? ClassInternal => null;
}

ReproLib/ReproComponent.razor

@inherits ReproBase
<div class="@ClassInternal">hello</div>

ReproLib/ReproComponent.razor.cs

namespace ReproLib;

public partial class ReproComponent
{
    protected override string? ClassInternal => "repro";
}

Steps:

1. Install .NET SDK 11.0.100-rc.1.26425.128 and make it the only SDK visible (DOTNET_ROOT and PATH pointing at that install).
2. Run docfx metadata docfx.json using docfx 2.80.1.

Expected behavior

Metadata extraction succeeds and the API of ReproComponent is produced — as it does with the .NET 10 SDK.

Context (please complete the following information):

• OS: Windows 10.0.26200 (win-x64)

• Docfx version: 2.80.1

• .NET version: 11.0.100-rc.1.26425.128 (fails); 10.0.401 (succeeds)

• docfx.json config

{
  "metadata": [
    {
      "src": [ { "src": ".", "files": [ "**/*.csproj" ] } ],
      "dest": "api"
    }
  ]
}

• Exceptions

// No exception is thrown - the run fails through diagnostics only (see below).

• Errors and warnings

warning: FailedToLoadAnalyzer: Failed to load .NET Analyzer. AnalyzerName: Microsoft.CodeAnalysis.Razor.Compiler, ErrorCode: ReferencesNewerCompiler, ReferencedCompilerVersion: 5.11.0.0
error: ReproComponent.razor.cs(5,32): error CS0115: 'ReproComponent.ClassInternal': no suitable method found to override
Creating output...
warning: No .NET API detected. Check the input files and earlier load or compilation diagnostics.

Build failed.

    2 warning(s)
    1 error(s)

• .NET info

// .NET 11 SDK used for the failing run (paths redacted):
 Version:           11.0.100-rc.1.26425.128
 Commit:            3551975be0
 Workload version:  11.0.100-manifests.a6e318ce
 MSBuild version:   18.11.0-1.26425.128+3551975be
 OS Name:     Windows
 OS Version:  10.0.26200
 OS Platform: Windows
 RID:         win-x64

Additional context

Control run: the identical repro with the identical docfx 2.80.1, on .NET SDK 10.0.401, gives Build succeeded. 0 warning(s) 0 error(s). Only the SDK differs between the two runs, which isolates the cause to the SDK's Roslyn version rather than to the project.

The same failure occurs on a real Blazor component library (20 errors of the CS0115 shape, one per code-behind override), which is how it was first noticed.

This appears to be the recurring class described in #10192. As long as Microsoft.CodeAnalysis.* is bundled, each SDK band that moves Roslyn forward will need another version bump like #11124.

For what it is worth, #10969 delegates MSBuild to the installed SDK via Microsoft.Build.Locator (ExcludeAssets="runtime"), but keeps Microsoft.CodeAnalysis.* as ordinary runtime package references. Since ReferencesNewerCompiler is a check performed by the Roslyn that loads the analyzer, that PR would — on my reading of the diff — not resolve this particular failure on its own, though it does address the MSBuild half. Happy to be corrected if the ForceBuild path is intended to cover it.