Loading net60 project into net472 host is not fully supported

[siegfriedpammer]

Issue Description

Note: I am not entirely sure where this bug report belongs, as I am using multiple components and it is hard for me to figure out, which component is failing.

Context

In my project I use the nuget packages for

• Roslyn (4.2)
• Microsoft.Build (17.2)
• Microsoft.Build.Framework
• and Microsoft.Build.Locator (1.4.1).

I use these tools to open solution files and projects and to perform some analysis on them.
My tool targets net472 and I select Visual Studio 2022 as Visual Studio instance using MSBuildLocator.

Example Program

Source code:

using Microsoft.Build.Locator;
using Microsoft.CodeAnalysis.MSBuild;
using System;
using System.Linq;
using System.Threading.Tasks;

namespace ApplicationConfigurationSourceGenNotExecutedInMSBuildWorkspace
{
    static class Program
    {
        public static async Task Main()
        {
            foreach (var vs in MSBuildLocator.QueryVisualStudioInstances())
            {
                PrintInstanceInfo(vs);
            }

            // When targeting net472 use this line:
            VisualStudioInstance selectedVS = MSBuildLocator.QueryVisualStudioInstances().FirstOrDefault(vs => vs.Name.Contains("2022")); // selects VS 2022
            // When targeting net60 use this line:
            //VisualStudioInstance selectedVS = MSBuildLocator.QueryVisualStudioInstances().FirstOrDefault(vs => vs.Version >= new Version(6, 0)); // selects net 6.0 sdk

            if (selectedVS == null)
            {
                Console.WriteLine("No SDK found!");
                return;
            }

            Console.WriteLine("Use " + selectedVS.Name);

            MSBuildLocator.RegisterInstance(selectedVS);

            var workspace = MSBuildWorkspace.Create();

            var project = await workspace.OpenProjectAsync(@"<path-to>\SDKStyleNet60WinForms.csproj");
            var comp = await project.GetCompilationAsync();

            if (comp == null)
            {
                Console.WriteLine("Project does not support compilation.");
                return;
            }

            foreach (var d in comp.GetDiagnostics())
            {
                if (d.IsSuppressed || d.Severity == Microsoft.CodeAnalysis.DiagnosticSeverity.Hidden)
                {
                    continue;
                }
                Console.WriteLine(d.Severity + ": " + d.GetMessage());
            }

            void PrintInstanceInfo(VisualStudioInstance instance)
            {
                Console.WriteLine($"Name: {instance.Name}");
                Console.WriteLine($"Version: {instance.Version}");
                Console.WriteLine($"MSBuildPath: {instance.MSBuildPath}");
                Console.WriteLine($"VisualStudioRootPath: {instance.VisualStudioRootPath}");
                Console.WriteLine($"DiscoveryType: {instance.DiscoveryType}");
            }
        }
    }
}

Project file:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net472</TargetFrameworks>

	<RoslynVersion>4.2.0</RoslynVersion>
	<MicrosoftBuildVersion>17.2.0</MicrosoftBuildVersion>
	<MicrosoftBuildLocatorVersion>1.4.1</MicrosoftBuildLocatorVersion>
  </PropertyGroup>

  <ItemGroup>
	<PackageReference Include="Microsoft.CodeAnalysis.Common" Version="$(RoslynVersion)" />
	<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="$(RoslynVersion)" />
	<PackageReference Include="Microsoft.CodeAnalysis.CSharp.Workspaces" Version="$(RoslynVersion)" />
	<PackageReference Include="Microsoft.CodeAnalysis.Workspaces.Common" Version="$(RoslynVersion)" />
	<PackageReference Include="Microsoft.CodeAnalysis.Workspaces.MSBuild" Version="$(RoslynVersion)" />
	<PackageReference Include="Microsoft.Build" Version="$(MicrosoftBuildVersion)" ExcludeAssets="runtime" />
	<PackageReference Include="Microsoft.Build.Framework" Version="$(MicrosoftBuildVersion)" ExcludeAssets="runtime" />
	<PackageReference Include="Microsoft.Build.Locator" Version="$(MicrosoftBuildLocatorVersion)" />
	<PackageReference Include="Microsoft.Build.Tasks.Core" Version="$(MicrosoftBuildVersion)" ExcludeAssets="runtime" />
	<PackageReference Include="Microsoft.Build.Utilities.Core" Version="$(MicrosoftBuildVersion)" ExcludeAssets="runtime" />
  </ItemGroup>
</Project>

When I try to open a .NET 6.0 SDK-style Windows Forms project (test-project.zip), then I get the error:
CS0103 The name 'ApplicationConfiguration' does not exist in the current context

Which is a hint that the new System.Windows.Forms.Generators.ApplicationConfigurationGenerator is not loaded/executed. This is a probably a bug, because I explicitly selected Visual Studio 2022 using MSBuildLocator.RegisterInstance and Visual Studio 2022 officially supports building net6.0 applications and opening the same project in VS 2022 executes the code generator just fine.

When I switch to net6.0 as the target framework of my code, then the project can be loaded/analyzed successfully.

However, not all of our users have the newest .NET SDKs installed, so targeting classic .NET 4.x for our analysis would be preferable.

So my questions are:

• Is this a bug?
  And if not:
• How are we supposed to support different versions of MSBuild / .NET with our project? (We have a wide range of frameworks and project types to support)
• Do I need to provide separate builds of my application for every (major) .NET version or is there an easier way?

[rainersigwald]

I would expect this to work fine from a net472 app (just like it does in Visual Studio itself!). I do think there's a bug, but I'm not sure it's in MSBuild. Moving this to Roslyn based on the analysis below.

I injected logging into the build with some environment variables

MSBUILDLOGTASKINPUTS=1
MSBUILDDEBUGPATH=S:\repro\dotnet\msbuild\issues\7765\logs
MSBUILDDEBUGENGINE=1

And compared that against a log from building the project under test with msbuild -bl.

I see the same analyzers passed to Csc there:

Analyzers
    C:\Program Files\dotnet\sdk\7.0.100-preview.5.22307.18\Sdks\Microsoft.NET.Sdk\targets\..\analyzers\Microsoft.CodeAnalysis.CSharp.NetAnalyzers.dll
        IsImplicitlyDefined = true
    C:\Program Files\dotnet\sdk\7.0.100-preview.5.22307.18\Sdks\Microsoft.NET.Sdk\targets\..\analyzers\Microsoft.CodeAnalysis.NetAnalyzers.dll
        IsImplicitlyDefined = true
    C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.5\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll
        FileVersion = 6.0.6.21309
        NuGetPackageVersion = 6.0.5
        Private = false
        PublicKeyToken = cc7b13ffcd2ddd51
        FrameworkReferenceVersion = 6.0.5
        ExternallyResolved = true
        NuGetPackageId = Microsoft.NETCore.App.Ref
        FrameworkReferenceName = Microsoft.NETCore.App
        AssemblyVersion = 6.0.6.21309
    C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.5\analyzers/dotnet/System.Windows.Forms.Analyzers.dll
        FileVersion = 6.0.422.16407
        NuGetPackageVersion = 6.0.5
        Private = false
        PublicKeyToken = 31bf3856ad364e35
        FrameworkReferenceVersion = 6.0.5
        ExternallyResolved = true
        NuGetPackageId = Microsoft.WindowsDesktop.App.Ref
        FrameworkReferenceName = Microsoft.WindowsDesktop.App.WindowsForms
        AssemblyVersion = 6.0.4.0
    C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.5\analyzers/dotnet/cs/System.Windows.Forms.Analyzers.CSharp.dll
        FileVersion = 6.0.422.16407
        NuGetPackageVersion = 6.0.5
        Private = false
        PublicKeyToken = 31bf3856ad364e35
        FrameworkReferenceVersion = 6.0.5
        ExternallyResolved = true
        NuGetPackageId = Microsoft.WindowsDesktop.App.Ref
        FrameworkReferenceName = Microsoft.WindowsDesktop.App.WindowsForms
        AssemblyVersion = 6.0.4.0

In fact, the compiler task invocations are almost identical; SkipCompilerExecution = True and a couple other things that don't seem critical were skipped.

That makes me suspect that it's something Roslyn is controlling that's limiting the generator here.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jcouv]

Moved to Area-IDE as we think this is a Workspaces API question/issue.
From chat with Jared, here's what we think is going on here:

            var workspace = MSBuildWorkspace.Create();
            var project = await workspace.OpenProjectAsync(@"<path-to>\SDKStyleNet60WinForms.csproj");
            var comp = await project.GetCompilationAsync();

The compilation returned by GetCompilationAsync() is likely the compilation without source-generated sources, as opposed to the second compilation that is created internally with added/generated sources.
So that would be a compilation without the outputs of ApplicationConfigurationGenerator. This results in a compilation where source is apparently missing (CS0103 The name 'ApplicationConfiguration' does not exist in the current context).

[JoeRobich]

@jasonmalinowski Any thoughts on this one?

[jasonmalinowski]

I believe MSBuildWorkspace may have limitations where it doesn't support .NET Core projects if it's compiled against .NET Framework. @DustinCampbell may remember whether that's what's going on, although as @rainersigwald observes that does seem odd since VS can do it just fine. It's possible that's an artifact from older .NET Core but the reasons behind that are long since changed.

@siegfriedpammer If you look at the project that was loaded by MSBuildWorkspace, and go to it's AnalyzerReferences collection, is it filled out as you expect?

[siegfriedpammer]

In the net60 case it contains:

In the net472 case it contains:

Note: I have no idea, why the MSBuildWorkspace would pick assemblies from .NET 7, if the project in question targets net60... I would expect the references from the first picture to be used in both cases.

[jasonmalinowski]

So @CyrusNajmabadi also just ran into a similar looking issue where he was trying to use our IDE Benchmarks project which would be a net472 project trying to load a net60 project. There were a bunch of load issues there:

Msbuild failed when processing the file 'C:\github\roslyn\src\Deployment\RoslynDeployment.csproj' with message: The SDK 'Microsoft.NET.Sdk' specified could not be found.
Msbuild failed when processing the file 'C:\github\roslyn\src\Compilers\Core\CodeAnalysisTest\Microsoft.CodeAnalysis.UnitTests.csproj' with message: The SDK 'Microsoft.NET.Sdk' specified could not be found.
Msbuild failed when processing the file 'C:\github\roslyn\src\Compilers\Core\Portable\Microsoft.CodeAnalysis.csproj' with message: The SDK 'Microsoft.NET.Sdk' specified could not be found.

So given there's .NET 7.0 stuff loading for a 6.0-targeting project, I'm guessing something (generally) about how SDK targeting is broken here.

@rainersigwald So say I fire up a command prompt and msbuild a SDK-targeting project. How is the SDK even picked there, high level? Do we have any docs?

[JoeRobich]

Note: I have no idea, why the MSBuildWorkspace would pick assemblies from .NET 7, if the project in question targets net60... I would expect the references from the first picture to be used in both cases.

Both .NET 6 and .NET 7 SDKs can build a net6.0 app. In the .NET SDK build you purposefully choose a .NET 6 MSBuild (and thus SDK) to build with. In the Full Framework build you simply choose a VS MSBuild which will use the highest SDK unless the project has pinned a specific one with a global.json.

[rainersigwald]

say I fire up a command prompt and msbuild a SDK-targeting project. How is the SDK even picked there, high level?

MSBuild has "SDK resolvers" that are a pluggable interface (with about 3 implementations, not really intended as end-user pluggable). One of them is the .NET SDK resolver, which uses .NET APIs (hostfxr_resolve_sdk2) to figure out the right SDK given global.json state and what's installed on the machine.

In the .NET SDK build you purposefully choose a .NET 6 MSBuild (and thus SDK) to build with.

This may also have been done inadvertently by targeting a .NET 6 runtime for your app that calls MSBuildLocator--Locator won't list a higher SDK major version than the current runtime major version because you can't load/build projects using that SDK (since they tend to depend on new runtime features).

In the Full Framework build you simply choose a VS MSBuild which will use the highest SDK unless the project has pinned a specific one with a global.json.

One subtlety: there's a minimumMSBuildVersion file in the SDK that may cause a too-new SDK to be rejected by a slightly-older MSBuild.

In the example I think it makes sense for MSBuild/the .NET SDK resolver to resolve SDK 7.0.100-preview since that's the highest version on the box.

[jasonmalinowski]

It also occurred to me right now is this just a lack of binding redirects in either @siegfriedpammer or @CyrusNajmabadi's case? Are those still required or does MSBuildLocator do the appropriate hooking in some way?

[siegfriedpammer]

This may also have been done inadvertently by targeting a .NET 6 runtime for your app that calls MSBuildLocator--Locator won't list a higher SDK major version than the current runtime major version because you can't load/build projects using that SDK (since they tend to depend on new runtime features).

So, the proper solution in our case is to always target the latest SDK?
I haven't tested it thoroughly, but I guess, net60 and newer are able to work with projects that target classic .NET Framework, even .NET Framework 2.0 or 3.x? Is that guaranteed?

The only other solution I can come up with is providing a separate build for each major SDK... which is a pity, because it adds a lot of "bloat" to our binary distribution.

Thank you for your interest and all the comments!

[sharwell]

I didn't read the full thread, but note that GetCompilationAsync doesn't automatically run source generators. You would need to manually run them similar to what you see here:
https://github.com/dotnet/roslyn-sdk/blob/1df5d394195ffcf6aab5b824ae420197ed1f0acc/src/Microsoft.CodeAnalysis.Testing/Microsoft.CodeAnalysis.SourceGenerators.Testing/SourceGeneratorTest%601.cs#L245

[siegfriedpammer]

Thank you for your response, @sharwell, however, I have a hard time understanding how to collect all the code generators prior to building in my code. Please understand that our customers are working with arbitrary code (ASP.NET, WPF, Windows Forms, whatever framework) and I have no control over which code generators are used.

For us the only important thing is that our program behaves exactly like "msbuild.exe /t:Rebuild some-project.sln" but instead of writing the compilation result to disk produces a full-fidelity Roslyn compilation that can then be analyzed. And it seems that using the MSBuild API properly to compile is impossible for WPF projects.

At this point I have to say I am very frustrated, because my job consists of 5% implementing my own code that does the analysis (and works!) and 95% trying to understand why OpenSolutionAsync/OpenProjectAsync does not behave the same as Visual Studio or MSBuild.exe.

Is there some documentation/guide on how to properly use the MSBuild APIs, so that they behave exactly the same as MSBuild.exe? Thank you very much!

[siegfriedpammer]

I have solved my problems with MSBuild.Locator and the MSBuild API by switching to the Buildalizer nuget package. I am now manually creating Compilations from the Buildalizer output and invoking the Analyzers/Generators manually. If you think there's nothing to improve, this can be closed. Thank you for all your helpful comments!

[stan-sz]

See related dotnet/wpf#6522