3.1.401 SDK fails to resolve correct available runtimes with 2.2.x

[daniefer]

Describe the bug

I have a have a single target project with the following config:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <IsPackable>false</IsPackable>
  </PropertyGroup>
</Project>

The build machine has dotnet core SDK. 2.2.402 and 3.1.401 installed. When I attempt to build this project, the following error is emitted and the build fails:

##[error]C:\hostedtoolcache\windows\dotnet\sdk\2.2.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(137,5): Error NETSDK1045: The current .NET SDK does not support targeting .NET Core 3.1.  Either target .NET Core 2.2 or lower, or use a version of the .NET SDK that supports .NET Core 3.1.

If I instead install SDKs 2.2.402 and 3.1.302 this error does not occur and the build succeeds.

To Reproduce

1. Install SDKs 2.2.402 and 3.1.401
2. Run msbuild.exe" "D:\a\1\s\MySolution.sln" /nologo /nr:false /dl:CentralLogger,"D:\a\_tasks\MSBuild_c6c4c611-aa2e-4a33-b606-5eaba2196824\1.166.2\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=|SolutionDir=D:\a\1\s"*ForwardingLogger,"D:\a\_tasks\MSBuild_c6c4c611-aa2e-4a33-b606-5eaba2196824\1.166.2\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:DeployOnBuild=true /p:PublishProfile=WebDeployPackage /p:configuration="Release" /p:_MSDeployUserAgent="VSTS_4522ee20-b1c7-418b-b3de-2bf24bb4eccd_build_43_0"
3. Error (see above)

Expected Result

The build should succeed.

Additional information

This was discovered on Azure DevOps. Nothing changes between the two builds other changing the Use .NET Core task to target 3.1.302 instead of 3.1.x.

Was there a breaking change in the last patch build or is this a bug?

[wli3]

In azure devops. 2 different SDKs will be in different location. And the later one will be "in front" on the environment PATH. So only the later one will be used when you run dotnet build. Could you show your PATH here? Please ensure there is no sensitive information.

[tankbob]

Just a note to follow up, I have the same problem, when I removed the build task for 2.2.? I got an error that msbuild was out of date. So is the error actually that when both sdk's exist and msbuild version is too low it automatically uses 2.2 version hence the error and the real reason is that devops is using an out of date version of msbuild?

[daniefer]

There are no path differences between using 3.1.401 vs 3.1.302. Here is the path from the agent running the build:

C:\Users\VssAdministrator\.dotnet\tools;C:/hostedtoolcache/windows/dotnet;C:\agents\2.173.0\externals\git\cmd;C:\Program Files\Mercurial\;C:\Program Files\MongoDB\Server\4.2\bin;C:\ProgramData\kind;C:\vcpkg;C:\cf-cli;C:\Program Files (x86)\NSIS\;C:\Program Files\Mercurial\;C:\hostedtoolcache\windows\stack\2.3.1\x64;C:\ProgramData\chocolatey\lib\ghc.8.10.1\tools\ghc-8.10.1\bin;C:\Program Files\dotnet;C:\mysql-5.7.21-winx64\bin;C:\Program Files\R\R-4.0.2\bin\x64;C:\Program Files\Java\jdk8u265-b01\bin;C:\SeleniumWebDrivers\GeckoDriver;C:\Program Files (x86)\sbt\bin;C:\Rust\.cargo\bin;C:\Program Files (x86)\GitHub CLI;C:\Program Files\Git\bin;C:\hostedtoolcache\windows\go\1.14.6\x64\bin;C:\hostedtoolcache\windows\Python\3.7.8\x64\Scripts;C:\hostedtoolcache\windows\Python\3.7.8\x64;C:\hostedtoolcache\windows\Ruby\2.5.8\x64\bin;C:\npm\prefix;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\windows\System32\OpenSSH\;C:\ProgramData\Chocolatey\bin;C:\Program Files\Docker;C:\Program Files\PowerShell\7\;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Binn\;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;C:\Program Files\nodejs\;C:\Program Files\OpenSSL\bin;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;c:\tools\php;C:\Program Files (x86)\sbt\bin;C:\Program Files (x86)\Subversion\bin;C:\SeleniumWebDrivers\ChromeDriver\;C:\SeleniumWebDrivers\EdgeDriver\;C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.3\bin;C:\Program Files\CMake\bin;C:\Program Files\Amazon\AWSCLIV2\;C:\Program Files\Amazon\SessionManagerPlugin\bin\;C:\Program Files\Amazon\AWSSAMCLI\bin\;C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin;C:\Users\VssAdministrator\.dotnet\tools;C:\Users\VssAdministrator\AppData\Local\Microsoft\WindowsApps

These are the setup steps and commands we are running to build this project

pool:
  name: Azure Pipelines
  demands: msbuild

#Your build pipeline references the ‘BuildConfiguration’ variable, which you’ve selected to be settable at queue time. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab, and then select the option to make it settable at queue time. See https://go.microsoft.com/fwlink/?linkid=865971

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk 2.2.x'
  inputs:
    version: 2.2.x

- task: UseDotNet@2
  displayName: 'Use .NET Core sdk 3.1.302'
  inputs:
    version: 3.1.302

- task: DotNetCoreCLI@2
  displayName: 'dotnet restore'
  inputs:
    command: restore
    vstsFeed: '**********************'

- task: MSBuild@1
  displayName: 'Build solution **/*.sln'
  inputs:
    configuration: Release
    msbuildArguments: '/p:DeployOnBuild=true /p:PublishProfile=WebDeployPackage'

- task: DotNetCoreCLI@2
  displayName: 'dotnet Publish'
  inputs:
    command: publish
    publishWebProjects: false
    projects: '**/ExampleProject.csproj'
    arguments: '-c $(BuildConfiguration) -o $(Build.ArtifactStagingDirectory)'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  inputs:
    PathtoPublish: '$(build.artifactstagingdirectory)'
  condition: succeededOrFailed()

Also, here is the output from the Setup for that pipeline run:

Starting: Initialize job
Agent name: 'Hosted Agent'
Agent machine name: '*********'
Current agent version: '2.173.0'
Current image version: '20200802.1'
Agent running as: 'VssAdministrator'
Prepare build directory.
Set build variables.
Download all required tasks.
Downloading task: UseDotNet (2.171.0)
Downloading task: PowerShell (2.170.1)
Downloading task: DotNetCoreCLI (2.173.0)
Downloading task: MSBuild (1.166.2)
Downloading task: PublishBuildArtifacts (1.158.3)
Checking job knob settings.
   Knob: AgentToolsDirectory = C:/hostedtoolcache/windows Source: ${AGENT_TOOLSDIRECTORY} 
   Knob: AgentPerflog = C:\agents\perflog Source: ${VSTS_AGENT_PERFLOG} 
Finished checking job knob settings.
Start tracking orphan processes.
Finishing: Initialize job

I will try to get a public pipeline (I think this is possible 🤔) defined that reproduces this to help with troubleshooting today.

[wli3]

in the path you have C:\Users\VssAdministrator.dotnet\tools;C:/hostedtoolcache/windows/dotnet

at one point, only one of them will be use in why run dotnet. So you need to make sure the first work in done, then the second one's path is appended to PATH

[daniefer]

Does the UseDotNet task not work with this new release then? I am confused why updating the version would suddenly cause a build failure. The dotnet cli is supposed to resolve the target framework even when multiple are installed I thought.

Also, which of these is not correct then?

C:\Users\VssAdministrator\.dotnet\tools; <=============================== #1
C:/hostedtoolcache/windows/dotnet; <=============================== #2
C:\agents\2.173.0\externals\git\cmd;
C:\Program Files\Mercurial\;
C:\Program Files\MongoDB\Server\4.2\bin;
C:\ProgramData\kind;
C:\vcpkg;
C:\cf-cli;
C:\Program Files (x86)\NSIS\;
C:\Program Files\Mercurial\;
C:\hostedtoolcache\windows\stack\2.3.1\x64;
C:\ProgramData\chocolatey\lib\ghc.8.10.1\tools\ghc-8.10.1\bin;
C:\Program Files\dotnet; <=============================== #3
C:\mysql-5.7.21-winx64\bin;
C:\Program Files\R\R-4.0.2\bin\x64;
C:\Program Files\Java\jdk8u265-b01\bin;
C:\SeleniumWebDrivers\GeckoDriver;
C:\Program Files (x86)\sbt\bin;
C:\Rust\.cargo\bin;
C:\Program Files (x86)\GitHub CLI;
C:\Program Files\Git\bin;
C:\hostedtoolcache\windows\go\1.14.6\x64\bin;
C:\hostedtoolcache\windows\Python\3.7.8\x64\Scripts;
C:\hostedtoolcache\windows\Python\3.7.8\x64;
C:\hostedtoolcache\windows\Ruby\2.5.8\x64\bin;
C:\npm\prefix;
C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;
C:\windows\system32;
C:\windows;
C:\windows\System32\Wbem;
C:\windows\System32\WindowsPowerShell\v1.0\;
C:\windows\System32\OpenSSH\;
C:\ProgramData\Chocolatey\bin;
C:\Program Files\Docker;
C:\Program Files\PowerShell\7\;
C:\Program Files\dotnet\; <=============================== #4
C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;
C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;
C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\;
C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;
C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\;
C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\;
C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Binn\;
C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;
C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;
C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;
C:\Program Files\nodejs\;
C:\Program Files\OpenSSL\bin;
C:\Strawberry\c\bin;
C:\Strawberry\perl\site\bin;
C:\Strawberry\perl\bin;
C:\Program Files\Git\cmd;
C:\Program Files\Git\mingw64\bin;
C:\Program Files\Git\usr\bin;
c:\tools\php;
C:\Program Files (x86)\sbt\bin;
C:\Program Files (x86)\Subversion\bin;
C:\SeleniumWebDrivers\ChromeDriver\;
C:\SeleniumWebDrivers\EdgeDriver\;
C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.3\bin; 
C:\Program Files\CMake\bin;
C:\Program Files\Amazon\AWSCLIV2\;
C:\Program Files\Amazon\SessionManagerPlugin\bin\;
C:\Program Files\Amazon\AWSSAMCLI\bin\;
C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin;
C:\Users\VssAdministrator\.dotnet\tools; <=============================== #5 
C:\Users\VssAdministrator\AppData\Local\Microsoft\WindowsApps

[wli3]

the dotnet cli is supposed to resolve the target framework even when multiple are installed I thought.

If they all installed to the same location like C:\Program Files\dotnet;

[daniefer]

I have put together this repo and Azure pipeline that shows how using version after 3.1.302 cause the build step to fail Repo: https://github.com/daniefer/sdk-build-issues/ Pipeline: https://dev.azure.com/danferguson/GitHub%20Issues/_build/results?buildId=66&view=results

Please let me know if you are unable to access either of those two links.

[wli3]

What is the reason that you install different versions of SDK? Newer version of SDK (but not the runtime) should be able to build older project.

[daniefer]

The windows-2019 container only contains 2.1 latest and 3.1 latest but we need to target 2.2 and 3.1. We have other projects in our solution that output nuget packages for 2.2 and 3.1. If I install just 2.2 with the UseDotNet task then msbuild cannot find 3.1. I suspect that is because the Path is modified so the default dotnet installed in the container is no longer able to be resolved.

[wli3]

If you just need to output 2.2 and 3.1 packages (not running 2.2 apps), you can only keep 3.1.xxx SDK and build everything using it. 3.1.xxx SDK can build 2.2 apps, if you need to run 2.2 apps, you need 2.2 runtime then.

[daniefer]

The actual build pipeline is compiling a web app for 2.2 in addition to creating packages for 2.2 and 3.1. Are you saying that we can compile 2.2 dotnetcore web apps using only the 3.1 sdk? If so, does that mean the test step in our pipeline would then be the one to fail because it does need to run with the 2.2 runtime.

[daniefer]

^ gentle reminder 😊

[wli3]

Sorry, we are closing to net5.0 release. Please expect a very long delay.

[wli3]

Are you saying that we can compile 2.2 dotnetcore web apps using only the 3.1 sdk?

Yes.

If so, does that mean the test step in our pipeline would then be the one to fail because it does need to run with the 2.2 runtime.

If you test, yes, it will fail to run. However I tried the following pipeline. If you install runtime and the SDK both in the same location. SDK will be able to find the runtime and run it.

- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: '3.1.402'
    installationPath: '$(Agent.ToolsDirectory)/dotnet1'
- task: UseDotNet@2
  inputs:
    packageType: 'runtime'
    version: '2.2.8'
    installationPath: '$(Agent.ToolsDirectory)/dotnet1'

dotnet --info result