Sdk: Resolver not failing when min msbuild version is specified.

[YunWeiaa]

Steps to reproduce

1. Create a new console app in VS
2. Update the content of minimumMSBuildVersion to 9999.3.0;
3. Reload the project

Expected behavior

There is 1 error in error list window:
_The current .NET SDK does not support targeting .NET Core 2.1. Either target .NET Core 1.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.1. _

Actual behavior

The project reload successfully without any error.

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.403
 Commit:    382c18c69d

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.403\

Host (useful for support):
  Version: 2.1.5
  Commit:  75426aea5c

.NET Core SDKs installed:
  1.1.10 [C:\Program Files\dotnet\sdk]
  2.1.402 [C:\Program Files\dotnet\sdk]
  2.1.403 [C:\Program Files\dotnet\sdk]
  2.1.500-preview-009297 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[livarcocc]

Thanks @YunWeiaa, @nguerrera please take a look.

[nguerrera]

Which minimumMSBuildVersion file was changed?

Was it C:\Program Files\dotnet\sdk2.1.500-preview-009297\minimumMSBuildVersion?

If so, this is actually new behavior in the resolver by design. What happens is that if the resolved latest SDK has minimumMSBuildVersion greater than the calling VS version, then it falls back to the newest one that is compatible. So here it would choose 2.1.403 instead of 2.1.500-preview-009297, which would still be able to load and build your project.

Try changing minimumMSBuildVersion in all of the SDKs listed in dotnet --info, and then you should see the old behavior. I will update the test instructions if/when I hear back that this worked.

[YunWeiaa]

I edit the minimumMSBuildVersion file under C:\Program Files\dotnet\sdk2.1.403\minimumMSBuildVersion

[livarcocc]

@YunWeiaa and what was the result? Did it work as expected?

[nguerrera]

Stepping back for a second, I am confused why dotnet --info is picking 2.1.403 instead of 2.1.500-preview-009297. Is there a global.json file specifying 2.1.403?

If so, and 2.1.403 has minimum version that is incompatible, I would actually expect this to fail.

[livarcocc]

@YunWeiaa is there a machine that we could TS to and try your setup ourselves?

[YunWeiaa]

@nguerrera yes, there is a global.json file specifying 2.1.403. This is what we need to test. Thank you for your explanation.

[YunWeiaa]

Repro on D15.9/28127.56(15.9 preview 3)

[richaverma1]

@nguerrera, @livarcocc, I have sent you repro machine details through email.

[YunWeiaa]

Also repro on D15.9/28128.56(15.9 preview 3)

[nguerrera]

I was able to reproduce this. The issue is that the resolver now has a cache of minimum msbuild versions for each SDK. So, you will not see any impact from it until you Visual Studio is restarted. This is by design since this file is never supposed to be edited. We are just doing that in the test plan to force some test coverage.

I have added the following extra steps to the test plan document:

• Close Visual Studio
• Check that there are no msbuild.exe tasks running in task manager
• Restart Visual Studio

[YunWeiaa]

Repro on D15.9/28217.54 (15.9 preview 4.0), even if following extra steps.

[nguerrera]

@YunWeiaa Was this tested in between D15.9/28128.56(15.9 preview 3) and D15.9/28217.54 (15.9 preview 4.0)? If so, did it not reproduce in between. Were the extra steps above and on OneNote to close VS and check that msbuild.exe is not running followed here?

cc @richaverma1

[YunWeiaa]

I re-check it on D15.9/28217.54 (15.9 preview 4.0) on another clean machine as the extra steps above, it doesn't reproduce.

[YunWeiaa]

Repro on D15.9/28219.56 (15.9 preview 4.0)+ CLI\SDK 2.1.500.

[richaverma1]

@nguerrera , Yun is testing SDK 2.1.500 which contains our new 2.1.6 runtime. This SDK is installed separately with 15.9 Preview 4 which comes with its own SDK. The reason for this scenario to be failing again seems to be your earlier explanation and let me know if that is what it is -
_" If so, this is actually new behavior in the resolver by design. What happens is that if the resolved latest SDK has minimumMSBuildVersion greater than the calling VS version, then it falls back to the newest one that is compatible. So here it would choose 2.1.403 instead of 2.1.500-preview-009297, which would still be able to load and build your project."_

[nguerrera]

@richaverma1 I will check the machine provided by email to confirm. The repro ultimately ended up involving a global.json, which changes that earlier explanation.

[nguerrera]

Logging on to the machine, I can't find any trace of a global.json having been used in the test and indeed without it and two different 2.1.500 SDKs installed, the SDK is falling back to the latest compatible SDK which is the other 2.1.500-* without the minimumBuildVersion changed. When I use global.json to try to pin to the version with altered minimumMSBuildVersion, then it fails as expected. I am going to try further clarifying some steps in the test plan as things are working by design from all that I can see.

[nguerrera]

There were some errors in the test plan. I have corrected them.

[YunWeiaa]

Following the updated steps, not repro on 2.1.6 build against d15.9/28226.55 (15.9 preview 5.0).