MSBuildWorkspace doesn't raise warnings or errors if the app is targeting too low of a version of Roslyn

[csaba-sagi-sonarsource]

On .NET SDK 7.0.307 I was able to use GetCompilationAsync to compile razor projects, however after updating to .NET SDK 7.0.4, it does not work anymore.

The issue might be related to this Roslyn issue, but I am not sure.
As I have described on that issue after updating to v7.0.4 a workaround needs to be applied to be able to load the project successfully. After loading the project successfully, the compilation succeeds too, but the razor-generated files cannot be seen in the syntax trees.

[glennawatson]

I'm having issues with GetCompilationAsync with not running the razor generator as well.

I have a blazor application. Scanning files with a code behind with .razor.cs extension.

I have the following code

using var workspace = MSBuildWorkspace.Create(
    new Dictionary<string, string>
    {
    { "EnableNETAnalyzers", "true" },
    });
workspace.LoadMetadataForReferencedProjects = true;

var solution = await workspace.OpenSolutionAsync(solutionFile.FullName);
var project = solution.Projects.FirstOrDefault(x => x.Name?.EndsWith(projectName, StringComparison.OrdinalIgnoreCase) ?? false);
var compilation = await project.GetCompilationAsync();
foreach (var document in project.Documents.Where(x => x.FilePath?.EndsWith("*.razor.cs", StringComparison.OrdinalIgnoreCase) == true))
{
    var syntaxTree = await document.GetSyntaxTreeAsync();

    if (syntaxTree is null)
    {
        continue;
    }

    var rootNode = await document.GetSyntaxRootAsync();

    if (rootNode is null)
    {
        continue;
    }

    var semanticModel = compilation.GetSemanticModel(syntaxTree);

    var syntaxDeclaration = rootNode.DescendantNodesAndSelf().OfType<ClassDeclarationSyntax>().First();
    
    var symbol = semanticModel.GetDeclaredSymbol(syntaxDeclaration);

    var isComponentType = symbol.AllInterfaces.Any(x => x.Name.Equals("IComponent"));
}

My expectation is for a interface called IComponent to exist in a blazor application for razor backed CS partial files, and the source generator to have run.

In 7.0.3 this is the outcome, in 7.0.4 I get no interfaces in the AllInterfaces

[davidwengier]

@jasonmalinowski @chsienki I assume you two are the experts here, not sure if this is a deliberate change, but it seems odd that multiple people have started hitting it today.

[jasonmalinowski]

We had another report of 7.0.400 breaking things due to the NuGet.Frameworks version problem, so that could be it here. That only shipped last week I think. @glennawatson: if you add an event handler for MSBuildWorkspace.WorkspaceFailed, is that being raised with an error while you call OpenSolutionAsync?

[chsienki]

What version of Microsoft.CodeAnalysis.* are you using?

Razor in 7.0.400 has a hard dependency on the 4.7 version of the compiler, so won't load if you're using 4.6.0.

I was able to repro using the above code when running on 4.6.0 but everything works as expected if you upgrade the code analysis packages to 4.7.0-2.final (note: that's pre-release because VS 17.7 isn't out yet, but is needed for the razor source generator in 7.0.400)

[glennawatson]

@chsienki using 4.6.0. Will try the prerelease version today.

[chsienki]

@jasonmalinowski As an aside, we (the compiler side) are raising an AnalyzerLoadFailed event in this case with the 'this analyzer needs a newer compiler message', but it doesn't look like its handled by the workspace code that's calling into it.

[glennawatson]

@jasonmalinowski i didn't see anything unusual in the workspace failed events.

[jasonmalinowski]

@chsienki Oh ouch, that's not good; we should probably raise that somwhere. Also:

note: that's pre-release because VS 17.7 isn't out yet, but is needed for the razor source generator in 7.0.400

We shipped 17.7 last week, looks like we're still working on shipping packages though.

[csaba-sagi-sonarsource]

I can also confirm that targeting 4.7.0-2.final version of Microsoft.CodeAnalysis.* fixes the issue. So, I guess this issue can be closed.
However, it would be nice to have some sort of indicator when this sort of dependency problem happens, instead of silently skipping the code generation.
Also, I am not super happy with the fact that I had to reference a prerelease version of a nugget package to make it work.

[jasonmalinowski]

The 4.7.0 packages should be out soon, there's a bit of a hangup due to some dependency issues we're having to sort out.

However, it would be nice to have some sort of indicator when this sort of dependency problem happens

Agreed; let's retitle this bug to reflect that fact!

[antonioaversa]

@jasonmalinowski
I reproduce a similar NuGet.Frameworks issue after moving from .NET SDK 7.0.400 to 8.0.100-rc.1.23463.5, with Microsoft.CodeAnalysis.* dependencies set to 4.7.0-2.final (latest available on nuget), when building a net8.0 Razor minimal project via MSBuildWorkspace.

The very same project builds correctly when the build is performed from Visual Studio (Community 2022 17.8.0 Preview 2.0).

The error message is the following: Could not load file or assembly 'NuGet.Frameworks, Version=6.8.0.69, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

The version of 6.8.0.69 of NuGet.Frameworks has not been released yet - the latest publicly available version is 6.7.0.

[jasonmalinowski]

@antonioaversa Yep, that's something we're working on fixing. Which TFMs was your app that was using MSBuildWorkspace targeting?

[antonioaversa]

@jasonmalinowski
The target frameworks of the project using the MSBuildWorkspace are net48;net8.0.
The target framework of the project being built by the MSBuildWorkspace is net8.0. It's a very simple Library project with Sdk="Microsoft.NET.Sdk.Web", no references, latest LangVersion and a couple of razor files.

[jasonmalinowski]

So I think this bug can now be closed since #61454 is closed too; I don't see anything that was specific in this otherwise that isn't fixed by OOP builds?

[jasonmalinowski]

Closing this now that the 4.9.0-2.final packages are out; if there's still issues people are running into it'd be best for us to have a new issue since there's a lot of different things being conflated here.