MSBuild Task on TFS 2018 failing with the wrong .net SDK Path

Question

I have a MSBuild task to build a service fabric project on TFS 2018 [On-Premises]. The solution builds fine locally using Visual Studio 2019 and MSBuild. It fails on the TFS Build Agent with the error..

Error NETSDK1045: The current .NET SDK does not support targeting .NET Core 3.1. Either target .NET Core 2.1 or lower, or use a version of the .NET SDK that supports .NET Core 3.1.

I explicitly configured the MSBuild task to use "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\msbuild.exe"

I am using the MSBuild task with the following parameters..

/p:Deterministic=true /t:Package /p:PackageLocation=$(build.artifactstagingdirectory)\applicationpackage

The TFS Build agent has both Visual Studio 2017 and 2019 installed. It also has the .Net core SDK 3.1 installed. [3.1.100 version].

For some reason the build output shows that the SDK is being picked up from "C:\Program Files\dotnet\sdk\2.1.602". It needs to use the SDK from "C:\Program Files\dotnet\sdk\3.1.100"

How do I force MSBuild task to use the SDK from C:\Program Files\dotnet\sdk\3.1.100.

I cannot add the "Nuget tools installer" task to the pipeline as our build agent does not have access to internet​

NOTE: The project was building fine using MSBuild from Visual Studio 2017 build task in TFS when we were on .net core 2.2.

We had to upgrade one the projects to .net core 3.1 and VS 2019 and it broke the build in TFS.

Contents of SFProj File:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" InitialTargets=";ValidateMSBuildFiles">
  <Import Project="..\..\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.props" Condition="Exists('..\..\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.props')" />
  <PropertyGroup Label="Globals">
<ProjectGuid>3b02cfa3-a4c3-49ea-9186-64ae171d64a7</ProjectGuid>
<ProjectVersion>2.3</ProjectVersion>
<MinToolsVersion>1.5</MinToolsVersion>
<SupportedMSBuildNuGetPackageVersion>1.6.7</SupportedMSBuildNuGetPackageVersion>
<TargetFrameworkVersion>v4.6.2</TargetFrameworkVersion>
  </PropertyGroup>
  <ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="Debug|x64">
  <Configuration>Debug</Configuration>
  <Platform>x64</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|x64">
  <Configuration>Release</Configuration>
  <Platform>x64</Platform>
</ProjectConfiguration>
 </ItemGroup>
  <ItemGroup>
<None Include="ApplicationParameters\Local.1Node.xml" />
<None Include="ApplicationParameters\Local.5Node.xml" />
<None Include="PublishProfiles\Local.1Node.xml" />
<None Include="PublishProfiles\Local.5Node.xml" />
<None Include="Scripts\Deploy-FabricApplication.ps1" />
  </ItemGroup>
  <ItemGroup>
<Content Include="ApplicationPackageRoot\ApplicationManifest.xml" />
<Content Include="ApplicationParameters\Params.xml" />
<Content Include="packages.config" />
  </ItemGroup>
 <ItemGroup>

<ProjectReference Include="..\Stateful1.csproj" />
</ItemGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.Common.targets" />
<PropertyGroup>
<ApplicationProjectTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Service Fabric Tools\Microsoft.VisualStudio.Azure.Fabric.ApplicationProject.targets</ApplicationProjectTargetsPath>
 </PropertyGroup>
<Import Project="$(ApplicationProjectTargetsPath)" Condition="Exists('$(ApplicationProjectTargetsPath)')" />
      <Import Project="..\..\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets" Condition="Exists('..\..\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets')" />
  <Target Name="ValidateMSBuildFiles" BeforeTargets="PrepareForBuild">
<Error Condition="!Exists('..\..\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.props')" Text="Unable to find the '..\..\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.props' file. Please restore the 'Microsoft.VisualStudio.Azure.Fabric.MSBuild' Nuget package." />
<Error Condition="!Exists('..\..\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets')" Text="Unable to find the '..\..\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.7\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets' file. Please restore the 'Microsoft.VisualStudio.Azure.Fabric.MSBuild' Nuget package." />
  </Target>
</Project>

Answer 1

The TFS Build agent has both Visual Studio 2017 and 2019 installed. It also has the .Net core SDK 3.1 installed. [3.1.100 version].

For some reason the build output shows that the SDK is being picked up from "C:\Program Files\dotnet\sdk\2.1.602". It needs to use the SDK from "C:\Program Files\dotnet\sdk\3.1.100"

To locate the cause of the issue:

Add a command-line task before your msbuild task, let it execute dotnet --info command to output the real sdk version used in your build. Check if it's using 3.1.100 version.

(Normally, dotnet --info will output available latest sdk version)

Possible Workarounds:

1.For agent itself: Since .net core SDK 3.1.100 supports VS2019 16.4 and above. So trying updating your VS2019 in TFS agent to latest version, and right-click .net core project in VS to check if 3.1 is available in drop-down list:

Sometimes you may need to reinstall or repair the .net core 3.1.100 sdk.

2.For Build:You can add use .net core task before your other tasks in build.

Specify this task to use 3.1.100 version and then subsequent tasks(MSBuild task) will also use this version.

Note: Use .net core task will take several minutes to download and install specified .net core sdk. So it's more recommended to configure sdk manually in local agent. Hope it helps :)

Answer 2

we went with a dedicated dotnet pool with only the VS 2019 build told installed. It's working now. Looks like, if we have VS 2017 and VS 2019 on the same agent machine, it's picking up VS 2017 build tools causing VS 2019 builds to fail.