MSBuildWorkspace: Unable to build hello world .netstandard2.0 class library anymore

[ceztko]

NOTE: I'm duplicating the issue from MSBuild tracker since I noticed the actual development of MSBuildWorkspace happens in roslyn repository.

Issue Description

Using MSBuild.Locator, Workspaces.MSBuild and the Roslyn infrastructure I'm unable to compile an hello world netstandard2.0 class library. The same library compile just fine when targeting .Net framework 4.5.2. I noticed the issue after I installed Visual Studio 16.8. Some releases before the same scenario was working.

Steps to Reproduce

1. Unpack the following test project:
   TestMSBuildWorkspaceCompilation.zip [UPDATE: Improved layout of the project]

2. Open TestMSBuildWorkspaceCompilation.sln;

3. Compile and run TestMSBuildWorkspaceCompilation project. When trying to compile the netstandard2.0 project an exception should trigger and compilation errors are printed. More explanations are in the code there.

Expected Behavior

No compilation errors should the issued when compiling the project targeting netstandard2.0.

Actual Behavior

A bunch of errors are printed, as the build system is unable to load the netstandard2.0 base library when compiling the project.

TestClassLibrary\obj\Debug\netstandard2.0\.NETStandard,Version=v2.0.AssemblyAttributes.cs[82..88)), CS0400: The type or namespace name 'System' could not be found in the global namespace (are you missing an assembly reference?)
TestMSBuildWorkspaceCompilation\TestClassLibrary\obj\Debug\netstandard2.0\TestClassLibrary.AssemblyInfo.cs[421..427)), CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?)
TestMSBuildWorkspaceCompilation\TestClassLibrary\obj\Debug\netstandard2.0\TestClassLibrary.AssemblyInfo.cs[497..503)), CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?)
[...]

Analysis

I'm currently using VS 16.9.2 but the same scenario was working some releases before 16.8.

Versions & Configurations

Microsoft.CodeAnalysis.*Workspaces* 3.9
Microsoft.Build.Locator 1.4.1
VisualStudio 16.9.2
.NET SDK 5.0.201
msbuild 16.9.0.11203

[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.

[JoeRobich]

@ceztko If you run dotnet restore against the net standard project first, does it open as expected?

[ceztko]

@JoeRobich Yes, it does. I updated the layout of the test project so you can run dotnet restore both against the project or the solution containing the project and it will workaround the issue with MSBuildWorkspace and the programmatic compilation. I have the feeling I didn't need this in the past. Should I assume this is indeed a bug or it's the expected behavior? Can I actually run a dotnet restore operation programmatically?

[ceztko]

Switching the library from netstandard2.0 to netcoreapp3.1 silences the issue, but of course it's not generally a valid workaround. It can help in some scenarios, though. I see the target for the fix is 16.10. Any chance the fix will be backported to 16.9 (which should be the servicing baseline for VS)?

[jmarolf]

@ceztko MSBuildWorkspace is just an API that ships as a nuget package I do not understand what porting it to 16.9 would mean

[ceztko]

@jmarolf ah, sorry. I read "Milestone 16.10" above and I thought the fix was related to some infrastructure package that is usually deployed together with VS (for example this is the case for msbuild). Ok, I will just wait for the next refresh of Microsoft.CodeAnalysis.* packages.

[ceztko]

Since the fix for this issue was delayed multiple times, is there a realistic milestone now?

[JoeRobich]

@ceztko I tried your example and reproduced your issue. I then ran dotnet restore against the netstandard project and reran your tool. This time it completed with no errors.

I believe this PR #61391 would help resolve your issue as you could additionally request a restore when you are loading the project into the workspace.

[ceztko]

@JoeRobich thanks, I hope the PR gets merged soon, and that there are no conflict of responsibility for the handling of this issue. Also, may I suggest to put the compilation of few simple projects (such as the ones I attached here) with MSBuildWorkspace under unit testing? I noticed such use case to be quite fragile and breaking easily, the last one in #58286 / microsoft/MSBuildLocator#176 which you are also following.

[ceztko]

Any update on this issue? Was the reload/restore API introduced eventually?