Some of our internal pipelines fail to build due to using out-of-support .NET SDKs

[konrad-jamrozik]

Our projects target out of support .NET versions, causing pipelines to fail, because they treat ".NET SDK version out of support" warnings as errors. For examples, see below.

I believe this problem occurs when a newest version of SDK is used to build a project targeting older version of SDK. Thus building project targeting net5.0 with net7.0 (i.e. currently latest) will fail the build (see ConfigureFabricBot example below), but building it with net5.0 won't (see e.g. this notification-configuration build). We end up building many projects with newest SDK, per #4935.

Notably, we use .NET Core 3.1.405 in globals.yml which will go out of support on December 13, 2022, presumably breaking most of our pipelines. I believe the breakage will happen only if net6.0 is used to build a project targeting obsolete .NET SDK, which is another reason to set .NET SDK instead of using latest one, per #4935.

Proposed fix

The fix to this problem is composed of following parts:

• Review all our .csproj files <TargetFrameowork> and retarget them to net6.0, per The template for prepare-pipelines is broken by the move to ubuntu-22.04 #4888 (comment).
  See PRs:
  • Update PipelineGenerator target framework from netcoreapp3.1 to net6.0 #4915
  • and Set .NET used by our tools to net6.0 + minor updates to .sln files #4937.
• Set the SDK versions of the projects by properly declaring them in ci.yml files; see Some of our tools use latest SDKs to build instead of specifically declared ones #4935 and PRs Update PipelineGenerator target framework from netcoreapp3.1 to net6.0 #4915 and Set .NET used by our tools to net6.0 + minor updates to .sln files #4937.
• Once the projects are migrated to .net6.0 and imminent threat of failure is mitigated, get rid of the SDK versions set per project, and instead set them globally, as done PR Bump globals.yml .NET SDK version from 3.1.405 to 6.x + assorted changes #4916.

Example failures

Below are some examples of failures:

tools - version-guard failure

Observe recent build failure of internal "tools - version guard" pipeline caused by:

/usr/share/dotnet/sdk/7.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.EolTargetFrameworks.targets(28,5): error NETSDK1138: The target framework 'netcoreapp2.1' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/dotnet-core-support for more information about the support policy. (...)

We can observe the project explicitly targets netcoreapp2.1.

The last successful build of the pipeline was on June 21, 2021.

tools - ConfigureFabricBot failure

Currently the pipeline tools - ConfigureFabricBot fails to build with:

/usr/share/dotnet/sdk/7.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.EolTargetFrameworks.targets(28,5): error NETSDK1138: The target framework 'net5.0' is out of support and will not receive security updates in the future. (...)

This is because net5.0 is also out of support, as of May 10, 2022.

Note the MSBuild version used was MSBuild version 17.4.0+18d5aef85 for .NET which corresponds to .NET 7.0.100.

Additional notes on the SDK used in version-guard

The ci.yml pipeline of the version-guard explicitly skips installing .NET SDK. It makes the build default to MSBuild version 17.4.0+18d5aef85 for .NET which corresponds to .NET 7.0.100 per table from Overview of .NET, MSBuild, and Visual Studio versioning / Lifecycle. Presumably this is because the pipeline uses MMSUbuntu20.04 for which the latest SDK version is 7.0.100 (see also description of PR #4930). 7.0.100 is being picked up in absence of explicitly declared SDK via UseDotNet@2, as its installation got skipped.

The skipping of SDK was merged on Jul 30, 2021, in PR #1853, while the last successful build of the pipeline was on June 21, 2021.

This information is related to #4935.

[konrad-jamrozik]

Closing. This issue has been addressed by these PRs:

• Update PipelineGenerator target framework from netcoreapp3.1 to net6.0 #4915
• Set .NET used by our tools to net6.0 + minor updates to .sln files #4937