UseDotNet@2 does not use version set for build

[tisis2]

Question, Bug, or Feature?
Type: Bug

Enter Task Name: UseDotNetV2

Environment

• Azure DevOps Server 2020 Update 1.2
• Windows Agent - 2.181.2

Issue Description

i created a branch for our project to migrate from net6 to net7. after the first build with net7 i recognized that also our master builds run with net7 sdk now. this should not happen since there is a UseDotNet@2 Task at the beginning of the pipeline with version 6.x and the documentation clearly says "... Use this task to change the version of .NET Core used in subsequent tasks. ..."

it seems that this task only really installs the dotnet sdk version but does not take care that subsequent tasks are using the version set.

[wrakocy]

Similar issue here.

[nilekirk]

We're seing this too, from today. And we're dependent on stuff that does not work in the presence of net7. So this is really bad - we have no working CI-builds, we can't ship stuff. And it just happened; we didn't change a thing.

[tisis2]

@nilekirk i placed a global.json in my repository root that sets sdk to 6.0.0 and only allows minor roll forward. maybe that helps as a workaround to be able to ship

[nilekirk]

@tisis2 Thanks, a global.json helped.

This is still a bug though - the task does not do what it says it does.

[tisis2]

@nilekirk yes its also a bug in my opinion... especially because one pipeline running on an agent can cause other pipelines to fail when they run later... happened that way to me... so i had to add the global.json to all my repos just because i created a branch for upgrading to net7 in one of them...

[github-actions]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[tisis2]

nobody of microsoft even interested? any updates?

[Berthelmaster]

Any updates? This is messing with two of our Linux Agents after Installtion .NET 8 rc-2 for a project.

[willisd2]

Ran into this exact issue using on-prem build agents. Created a branch to upgrade my project from .NET 6 to 7, and after a build kicked off against the branch, it started breaking pipelines for all the other branches still on .NET 6... Our build is structured where it does a UseDotNet@2 first, telling it to go off of the global.json. The next step does a dotnet restore on the solution which ends up using the .NET 6 SDK defined in the global.json. The next step does a dotnet build on the csproj's with a --no-restore option, which ends up ignoring the global.json and uses the .NET 7 SDK instead. This causes it to error out and fail the build.

[foomaniac]

Disappointed to have stumbled across this issue to find it's unresolved. Seems this is happening now.

Because of another bug in .net 8 preventing build steps from authenticating against an Azure DevOps private nuget feed anymore, we've been trying to find ways to allow us to upgrade to .net 8 without having to update every single one of our 100+ existing pipelines to add the auth step in.

In short, I've discovered that if we want to ensure that an agent defaults to .net 6, the only way to do this is to place a global.json at the root of the agent's folder.

The content of this global.json is below:

{
  "sdk": {
    "version": "6.0.201",
    "rollForward": "minor"
  }
}

We then looked to use the 'Use Dot Net SDK' task step to specify .net 8 for the relevant upgrade pipelines. Nothing in the documentation states that it wouldn't override the global.json file. https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/use-dotnet-v2?view=azure-pipelines

Infact, there's an option to tell it to use the global.json if you want to.

Instead what is happening is, despite it successfully (apparently) setting the version to .net 8 as we're asking. Subsequent steps are still defaulting to the .net 6 version.

All appears fine, until the next dotnet cli command runs...

(BTW Yes I know in the screenshot it says .net 7, as much as microsoft can't be bothered to fix these issues, I can't be bothered going back to find the correct failed build that shows .net 8 but trust me, it still fails)

You can see the sdk version the dotnet command is running against is still 6, and the build fails because it isn't finding the version it expects. So the 'Use Dot Net SDK' step is not doing what it's supposed to do at all.

We're so close to sacking off .net 8, add in the other issue we have dotnet/sdk#37379 (comment) and also this one dotnet/efcore#25555 which is preventing us upgrading projects that use ef bundling regardless of this ticket's issue, it just makes Microsoft come across pretty poor at the moment.

[mhborg-timextender]

We have the same problem on ours, UseDotNet@2 is just being ignored in favor of the default one on our self-hosted agent.

[FRANKR318]

I have the same problem! When will this be fixed?

[L-Markham]

I have the same problem! When will this be fixed?

It never will be. This thread has been open for a year and a half, and Microsoft has yet to reply; extremely poor response from them.