DEV Community

Cover image for Selecting what .NET version is to use
It's actually me
It's actually me

Posted on • Originally published at keepontruckin.hashnode.dev on

Selecting what .NET version is to use

I'm a little procrastinated, not gonna lie. The Alertbox Inc. (@alertbox) pipelines page is open on my work PC and one of the CI pipelines is broken. What a SHAM!

It's a little weird since the pipeline logs show the target .NET version net5.0 isn't available, but the changeset seems to work locally. Not only are there no tests failing, but there are no errors at all. For the record, Alertbox has several hundred git repos and pipelines that they run quite often on hosted agents. The truth is they have not upgraded the .NET used by the code repos to the latest version, so they require several .NET versions installed locally.

2017-06-10_budget_money_spending_projects_upgrades_technology_software_engineering

Maybe they don't have .NET end-of-life support versions on hosted agents anymore? Yup! The Azure Pipeline team is upgrading the .NET used by pipeline agents. I almost want to upgrade the .NET used by the code repo to the latest LTS version, say, replacing TargetFramework to net6.0 from net5.0 and running dotnet list package --outdated to see what packages are to upgrade. You'd be amazed how problematic is it to have several .NET versions running locally since the dotnet driver selects the latest SDK installed locally for commands and not from the entry project / solution that's in, so it would be difficult to figure out what packages are to upgrade without going thru all of them one at a time completely. And .NET Core 3.1 will be end-of-life support soon, so that means more code repos to upgrade.

It's not such a great idea and probably not even pragmatic to go thru all of that Jazz and upgrade each one since you can only boil so many oceans at the same time, so it's definitely necessary to break out that pipeline and modify the YAML script to install any end-of-life support .NET versions.

#.azuredevops/steps/build.yaml
steps:
# Install .NET from global.json
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    useGlobalJson: true
Enter fullscreen mode Exit fullscreen mode

All I need to do is add a UseDotNet task as a prerequisite for the build step and it will install .NET on pipelines for me. But there are more problems. They require a global.json file to figure out what SDK version is to install.

// global.json
{
  "sdk": {
    "version": "5.0.408",
    "allowPrerelease": false,
    "rollForward": "latestMinor"
  }
}
Enter fullscreen mode Exit fullscreen mode

I can run dotnet --list-sdks to get the SDK version that is running on my work PC, and then run dotnet new globaljson to create the global.json file to mention that SDK version. Then I can run the pipeline and the UseDotNet@2 task will take care the rest for me. Excellent! Moving right along.

# Trigger the pipeline
az pipelines run \
   --branch kp/fix-23-dotnet-not-found \
   --folder-path ci \
   --name ca-cocktails \
   --output table \
   --open
Enter fullscreen mode Exit fullscreen mode
# Check for build status
az pipelines runs list \
   --top 3 \
   --status all \
   --branch kp/fix-23-dotnet-not-found \
   --output table
Enter fullscreen mode Exit fullscreen mode

It's taking a few tries to get the pipeline green since some of the dependencies and C# features don't seem to recognize anymore since .NET 5 only supports C# 9 and not latest version. This may be difficult. I'll come back to this later!

/KP

Top comments (0)