Azure DevOps Pipeline doesn't support .NET 6? (VS2019 on windows-latest pool)

[mikeKuester]

Description

I upgraded my project from .NET 5 to .NET 6 and wanted to execute a "build, test and publish" pipeline on Azure DevOps. That fails because the hosted agent does not support .NET 6 by default.

pool:
  vmImage: 'windows-latest'

I added an UseDotNet task in order to install the .NET 6 SDK which works, but that the build task failed ...

- task: UseDotNet@2
  displayName: 'Install .NET 6 SDK'
  inputs:
    packageType: 'sdk'
    version: '6.0.x'
    performMultiLevelLookup: true

telling me, that Visual Studio 2019 does not support .NET 6.

##[warning]C:\hostedtoolcache\windows\dotnet\sdk\6.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.DefaultItems.targets(134,5): Warning NETSDK1182: Targeting .NET 6.0 in Visual Studio 2019 is not supported.

I tried to set the "Compatible Visual Studio version", but than seems to be ignored:

    vsVersion: '17.0.0'

I would expect, that after the official release of .NET 6 the "latest" hosted agents would also support this new version.

Configuration

Regression?

Other information

[mairaw]

@richlander who would know about what's supported on the latest images?

I am using vmImage: windows-2022 on my pipeline with .NET 6 SDK and that works for me. I haven't tried with windows-latest yet to see if it would work for me as well. I can give it a try and report back.

[mikeKuester]

@mairaw Thank you, if I switch to windows-2022 the build process starts (and fails later with NETSDK1152: Found multiple publish output files with the same relative path). With that host I can also remove the UseDotNet task.

It would be fine, if the windows-latest would always work with the actual .NET version ;)

[mairaw]

I'm trying to find the owner for this so we can have a definitive answer.

[RyantheLeon]

I'm trying to find the owner for this so we can have a definitive answer.

That'd be great. The UseDotNet task worked for me, but I'd much rather define that I'm using .net 6 in one place (within the project, not also in the pipeline) and for everything else to reference that.

[dasMulli]

telling me, that Visual Studio 2019 does not support .NET 6.

VS 2019 (windows) does not support .NET 6, for example as per the downloads page of the .NET 6 SDK:

Visual Studio support
Visual Studio 2022 (v17.0)
Visual Studio 2019 for Mac (v8.10)

How are you building your applicaton? If you use the - task: DotNetCoreCLI@2 tasks to build your app, you should be fine on the windows-latest image. If you use the visual studio build tasks, they will not work (as windows-latest is still VS2019)

NETSDK1152: Found multiple publish output files with the same relative path

This is likely not related to the build image. Does an equivalent dotnet publish command work in your project folder or publishing from your local Visual Studio 2022?

[mikeKuester]

Ok, I found this page now Microsoft-hosted agents with the installed software on the different hosts.

• Windows Server 2022 with Visual Studio 2022 --> windows-2022
• Windows Server 2019 with Visual Studio 2019 --> windows-latest OR windows-2019

I didn't expect, that the "windows-latest" is no the latest ... :( (clean code: meaningful names?) With that info it's clear.

And your are right, I got the NETSDK1152 error also on a local publish. (I changed the target framework, fixed the bugs, run the tests and than I tried directly the pipeline.) There was an obsolete appsettings.json file in a second project.

With that I run into the next error during the test execution in the pipeline:

- task: VSTest@2
  displayName: 'Run tests & publish results"'
  inputs:
    testRunTitle: 'Hardware Independent'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'
    testAssemblyVer2: '$(testDll)'
    codeCoverageEnabled: true
    runInParallel: true
    rerunFailedTests: true
    rerunMaxAttempts: 3
    testFiltercriteria: 'TestCategory~hardware independent'

I didn't set "vsTestVersion" which should use again the "latest" Version. But it looks for a vstest.console from a visual studio installation with version [16.0,17.0) but couldn't find it?

Starting: Run tests & publish results"
==============================================================================
Task         : Visual Studio Test
Description  : Run unit and functional tests (Selenium, Appium, Coded UI test, etc.) using the Visual Studio Test (VsTest) runner. Test frameworks that have a Visual Studio test adapter such as MsTest, xUnit, NUnit, Chutzpah (for JavaScript tests using QUnit, Mocha and Jasmine), etc. can be run. Tests can be distributed on multiple agents using this task (version 2).
Version      : 2.170.1
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/test/vstest
==============================================================================
SystemVssConnection exists true
SystemVssConnection exists true
Running tests using vstest.console.exe runner.
======================================================
Test selector : Test assemblies
Test filter criteria : TestCategory~hardware independent
Search folder : D:\a\1\s
Action when minimum tests threshold not met : donothing
Minimum tests expected to be run: 0
VisualStudio version selected for test execution : latest
Attempting to find vstest.console from a visual studio installation with version [16.0,17.0).
Attempting to find vstest.console from a visual studio build tools installation with version [16.0,17.0).
Attempting to find vstest.console from a visual studio installation with version [15.0,16.0).
Attempting to find vstest.console from a visual studio build tools installation with version [15.0,16.0).
##[error]Error: Visual Studio 2015 is not found. Try again with a version that exists on your build agent machine.
Finishing: Run tests & publish results"

[mikeKuester]

Setting vsTestVersion: '16.0' doesn't help. I open an issue at microsoft/azure-pipelines-tasks for that.

[dasMulli]

Good to hear about your progress! personally I‘m mostly using the DotNetCLI task as well to run tests and publish result (works for SDK-based test projects)

[schovan]

I fixed it adding this to yaml file:

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

It works with:

pool:
  vmImage: 'windows-latest'

[mikeKuester]

But you don't use VSBuild or VSTest Task, do you?

[RyantheLeon]

I fixed it adding this to yaml file:

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

I agree that this works, and I'm grateful for it. It'd also be nice to have a more permanent fix. This won't work if there's a .net 6.1, or when .net 7 comes out.

[schovan]

But you don't use VSBuild or VSTest Task, do you?

I use DotNetCoreCLI@2.

[Ogglas]

Imao .NET 6 SDK should be added to vmImage: 'windows-latest' as default.

It is marked as recommended when downloading .NET and it is the current Long-term support (LTS) version.

https://dotnet.microsoft.com/download/dotnet

[mikeKuester]

As long as the latest image is the Windows Server 2019 with Visual Studio 2019 it wouldn't help in all cases, for example VSTasks won't run, because .NET 6 needs VS 2022.

The latest image should always be the lastest and not the second latest.

[Pentadome]

What is microsoft doing? Why is windows-latest not latest? Why does VSTest ignore visual studio 2022? Why is Dotnet 6 a 'full' release when Microsoft doesn't properly support it?

[schovan]

What is microsoft doing? Why is windows-latest not latest? Why does VSTest ignore visual studio 2022? Why is Dotnet 6 a 'full' release when Microsoft doesn't properly support it?

I remember when .Net 5.0 was released, it also did't work without UseDotNet@2 fix. They fixed it later. I don't remember the exact time.

[brux88]

i have the same error

[davidrevoledo]

I have the same problem

With vmImage: 'windows-latest' it doesnt work even using DotNetCoreCLI@2

[Brendan-33]

So at this point windows-latest does not default to windows-2022, which is needed to build/unit test .NET 6 (C# 10) projects.

Here is a working pipeline that I pulled from these 2 blog posts:
Azure DevOps - The Feature 'Global Using Directive' is currently in Preview
Azure Devops - The current .NET SDK does not support targeting .NET 6.0

This is a fully working Azure DevOps pipeline for a .NET 6.0 project using C# 10.0:

# ASP.NET Core (.NET Framework)
# Build and test ASP.NET Core projects targeting the full .NET Framework.
# Add steps that publish symbols, save build artifacts, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core

trigger:
- master

pool:
  vmImage: 'windows-2022'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:

# Add this Command to Include the .NET 6 SDK
- task: UseDotNet@2
  displayName: Use .NET 6.0
  inputs:
    packageType: 'sdk'
    version: '6.0.x'

# Add a Command To List the Current .NET SDKs (Sanity Check)
- task: CmdLine@2
  inputs:
    script: 'dotnet --list-sdks'

- task: NuGetToolInstaller@1

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  inputs:
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

[dasMulli]

(disclaimer: not working for MS/GH, this comes from experience following the updates for a quite a while)

New images are usually tested for a few months to make sure people starting to use it (like all of us) don't run into unexpected issues in build scripts. That means waiting to see if people migrating to VS 2022 / .NET 6 / * open issues for something not working.

Then default image changes are rolled out incrementally - monitoring build failures and tickets. Again, you don't want to break thousands of people by changing the defaults unexpectedly and without prior notice. I too would be happy to not wake up the whole company being unable to complete work due to stuck CI/CD builds just because VS 2022 came out and most projects are still on .NET 3.1 LTS / VS2019 and not being updated on Day 0.

If you are asking for changing windows-latest immediatly, I would ask to keep it the current way.

From actions/runner-images#4488:

When will windows-latest be replaced by windows-2022?

it will be announced, but not early than next year

[mikeKuester]

Thanks to @dasMulli for the info. The behaviour that you discribe, would I expect if I use something like windows-stable ... ;)

[mairaw]

I followed up internally on this as well. Here's the response I got:

"It is a long process for us to update the windows-latest label to point to the latest Windows image. The moment we do this, we break a number of customers. So, when we release a new image like windows-2022, we give a long notice (about 3-4 months), wait for people to gradually move their builds, and then update the image label. FYI, windows-latest pointed to windows-2016 until 3 months ago. You can follow the shifts in these labels from our release notes and from the GitHub pages.

Release notes: https://docs.microsoft.com/en-us/azure/devops/release-notes/2021/sprint-194-update

Sample item in release notes about latest image: https://docs.microsoft.com/en-us/azure/devops/release-notes/2021/sprint-193-update#macos-latest-label-will-soon-point-to-macos-11-image"

I'd keep an eye on the Microsoft-hosted agents article for updates. But for now, the windows-2022 is the right one to use.

Closing this issue since this behavior is by design according to the product team.

[EnCey]

FYI, windows-latest pointed to windows-2016 until 3 months ago

As others have already pointed out, should the name really be windows-latest then, if it can take months for it to actually use the latest version?

The reasons for why a switch can't happen over night make sense, but the name is still extremely misleading. Especially for people who set up a new project. I concur with others here that windoes-stable would be much more appropriate.

[dasMulli]

@EnCey suggest you open that as in issue on https://github.com/actions/virtual-environments

[aidan-rypens]

Use .NET 6.0 SDK --> Takes 1.30minute. Are there any options to improve this?

[mikeKuester]

If you select windows-2022 as host, the SDK is directly available. No need for the UseDotNet task.

[aidan-rypens]

Hmm, didn't work on my end. It still took some time to download & install the SDK.

Ended up using ubuntu to speed it up. Seems a bit weird that this is faster than a windows image?
Or is it normal as it is like slimmer / faster?

[IanKemp]

It is a long process for us to update the windows-latest label to point to the latest Windows image. The moment we do this, we break a number of customers.

Sorry, but this is nonsense: customers that choose to use the windows-latest image are not Microsoft's problem. If they want an image that won't change out from under them, they should have selected a specific image like windows-2019, or built their own.

Stop mollycoddling developers who are too lazy to setup build and release pipelines correctly.

[PaladiAlexandru]

I have the same problem, only that i'm using sonarcloud and i get this

[mairaw]

Here's the issue tracking this update: actions/runner-images#4856

[LittleLittleCloud]

Hitting the same issue here as well

[Prinsn]

It is a long process for us to update the windows-latest label to point to the latest Windows image. The moment we do this, we break a number of customers.

Sorry, but this is nonsense: customers that choose to use the windows-latest image are not Microsoft's problem. If they want an image that won't change out from under them, they should have selected a specific image like windows-2019, or built their own.

Stop mollycoddling developers who are too lazy to setup build and release pipelines correctly.

While I agree to an extent, I want to counter with the fact that this implicitly codifies the notion that Developers and DevOps should not be distinct from one another, and that Developers need to know literally everything to do literally anything, which is a death spiral.

I'm running into this upgrading to .NET 6 when I've literally never had to interact with this aspect of Azure DevOps for my 5 years of experience with it.

I do otherwise agree that "latest" is "latest", and that they should have a different keyword if you want "latest-verified"

Hitting the same issue here as well

✋

[mairaw]

I'd suggest that you start a discussion on the https://github.com/actions/virtual-environments repo about this. This is not something the .NET team controls it.

[coinzdude]

@brendansluke Your pipeline example worked perfectly. Thank you for sharing!

[HydTechie]

Update Agent Specification in Azure DevOps pipeline to Windows 2022, Working fine after that!!!

[SiripuramKrishnakumar]

Update Agent Specification in Azure DevOps pipeline to Windows 2022

Yes it's working.

[benjaminoerskov]

I have the same problem, only that i'm using sonarcloud and i get this

You need to use both net6.0 and net3.1 to run sonarcloud with net6.0. Works for me :)