1
votes

There are several places online where people mention having trouble with Azure DevOps having trouble using things like the .NET Core 3.1 SDK. Typically the advice is to use the Use .NET Core task to switch Azure DevOps over to 3.1 from whatever version it is on previously, and often this works.

In my case, Azure DevOps still can't tell that 3.1 is installed. Even if I log onto the Agent machine (we're using our own agents), uninstall everything but the 3.1 SDK, and reboot, Azure DevOps still tries to use 2.0 or something.

Immediately before the Visual Studio build task, I have a Command line task with the following script:

dotnet --info

This yields, minus some extra text at the beginning and end, the following:

.NET Core SDK (reflecting any global.json):
 Version:   3.1.102
 Commit:    573d158fea

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

Host (useful for support):
  Version: 3.1.2
  Commit:  916b5cba26

.NET Core SDKs installed:
  3.1.102 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

The very next task, Visual Studio build, lists errors such as these:

##[error]C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.TargetFrameworkInference.targets(112,5): Error : The current .NET SDK does not support targeting .NET Core 3.1.  Either target .NET Core 1.1 or lower, or use a version of the .NET SDK that supports .NET Core 3.1.
.
.
.
##[error]C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.TargetFrameworkInference.targets(126,5): Error : The current .NET SDK does not support targeting .NET Standard 2.0.  Either target .NET Standard 1.6 or lower, or use a version of the .NET SDK that supports .NET Standard 2.0.

It essentially does this whether I include the Use .NET Core task or not.

Before uninstalling the .NET Core 2.1 SDK from the machine, it would be trying to use .NET Core 2.1, not 1.1. The errors would ask for 2.1 in that scenario.

Before 2.1, if I used Use .NET Core and set it to 3.1.x, it would work successfully, but then the build task would throw essentially the same exact errors as above, refusing to even use 2.1 at that point.

It may be useful to mention that this is a VS2017 project, and the OS version is Microsoft Windows Server 2019 Datacenter.

...Why can't it see the 3.1 SDK?

1

1 Answers

6
votes

I can't comment (not enough Karma), but it sounds like you're trying to compile a .NET core project using the wrong Build process. It looks like you're trying to get Visual Studio 2017 to build a Core project, when in Azure DevOps there is a Core build task, under the .Net Core task.

if it's a true Core 3 project, use the ".NET Core" Task to run your build.

We use the following in DevOps Pipeline:

  • Use .NET Core (sets the version on the machine) (you've done this bit).
  • .Net Core Task -> Restore
  • .Net Core Task -> Build
  • .Net Core Taks -> Test
  • .Net Core Task -> Publish

Core Build Tasks

You're effectly telling DevOps to use an older version of the Visual Studio Build engine, that has no knowledge of the .Net Core runtimes you're trying to use, to build your project.

If you're wondering what's going on here, Visual Studio Only Targets the Full-Framework, or versions of .Net core that version of VS knows about in it's build steps (which is why you're getting the SDK errors). When you're developing in visual studio, it can target any core vesion you have installed on your local machine because it's reading your csproj file settings to look for the version to target and Visual studio then effectively "shells" out to the local core install for the build. DevOps can't do that, as the tooling that's installed with the Visual Studio Build step isn't the same as your local machine and can only target certain SDK's