MSBuildWorkspace does not cleanly load blazorwasm project

[JoeRobich]

Version Used: 4.10 Preview 1

Reported in #69225

Steps to Reproduce:

1. dotnet new blazorwasm (or blazor or blazorwasm-empty)
2. use MSBuildWorkspace.OpenProjectAsync to load the newly created project

Expected Behavior:
Project loads without any workspace diagnostics and compilation reports no compiler diagnostics.

Actual Behavior:
Compilation reports "CS0246: The type or namespace name {'csharp_blazor_project'|'App'} could not be found (are you missing a using directive or an assembly reference?)"

Possibly unrelated
I noticed that the C# extension in VS Code reports the following when opening the blazorwasm project.

Generator 'RazorSourceGenerator' failed to initialize. It will not contribute to the output and compilation errors may occur as a result. Exception was of type 'TypeLoadException' with message 'Type 'Microsoft.CodeAnalysis.ExternalAccess.RazorCompiler.HostOutputNode`1[TInput]' from assembly 'Microsoft.CodeAnalysis.ExternalAccess.RazorCompiler, Version=4.8.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' is attempting to implement an inaccessible interface.'.
System.TypeLoadException: Type 'Microsoft.CodeAnalysis.ExternalAccess.RazorCompiler.HostOutputNode`1[TInput]' from assembly 'Microsoft.CodeAnalysis.ExternalAccess.RazorCompiler, Version=4.8.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' is attempting to implement an inaccessible interface.
   at Microsoft.CodeAnalysis.ExternalAccess.RazorCompiler.GeneratorExtensions.RegisterHostOutput[TSource](IncrementalGeneratorInitializationContext& this, IncrementalValuesProvider`1 source, Action`3 action)
   at Microsoft.NET.Sdk.Razor.SourceGenerators.RazorSourceGenerator.Initialize(IncrementalGeneratorInitializationContext context)
   at Microsoft.CodeAnalysis.GeneratorDriver.RunGeneratorsCore(Compilation compilation, DiagnosticBag diagnosticsBag, CancellationToken cancellationToken) in /_/src/Compilers/Core/Portable/SourceGeneration/GeneratorDriver.cs:line 226

[jasonmalinowski]

@jaredpar @chsienki @jjonescz I'm wondering if this was broken by #71579. The generator being loaded from the SDK is one that still expects the ExternalAccess to be there, but we don't have it any more for newer Roslyn builds.

This seems like fallout for how the razor generator is expected to load:

• in a dotnet build, the SDK bits are all matched.
• in VS for Windows, we're loading the generator that ships in the IDE so it's matched with the compiler bits there
• for VS Code we're discussing doing the same thing, but we're not doing that yet, which might explain the error @JoeRobich saw
• for MSBuildWorkspace we'll do...what? We're not shipping a Razor generator to load from anywhere that may match the Roslyn version the user's app is.

[jjonescz]

If I read the error message correctly, the ExternalAccess.RazorCompiler dll is present, it just cannot implement internal CodeAnalysis interface anymore. I think we could just keep the IVT around to solve this (#71579 (comment)).

[jasonmalinowski]

@jjonescz Does that mean at this point the expectation is the core compiler binaries are always maintaining the APIs that the old ExternalAccess was accessing?

[JoeRobich]

Verified locally that the fix @jjonescz proposes will resolve this issue.

[jjonescz]

Does that mean at this point the expectation is the core compiler binaries are always maintaining the APIs that the old ExternalAccess was accessing?

Hm, good question. It should be enough if we keep them as stubs (if we want to remove or rename them in the future) - because the razor compiler doesn't rely on them working (the machinery was supposed to be used by razor IDE to get design-time outputs out of the razor compiler).