20241113.3.0 breaks our build due to increased build warnings

[ptemmer]

Description

Without any code changes, we have noticed that builds scheduled on agents with version 20241113.3.0 see a much higher number of build warnings (in the form of package vulnerabilities). This breaks our build as we have the build quality check plugin enabled, to ensure that our build warnings do not increase.

Example of the build warnings we started seeing:

D:\a\1\s\packs\Helpers\Helpers.csproj : warning NU1903: Package 'Microsoft.Extensions.Caching.Memory' 8.0.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-qj66-m88j-hmgj [D:\a\1\s\apps\ConsoleApp\ConsoleApp.csproj]
D:\a\1\s\packs\Helpers\Helpers.csproj : warning NU1903: Package 'System.Text.Json' 8.0.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-8g4q-xg66-9fp4 [D:\a\1\s\apps\ConsoleApp\ConsoleApp.csproj]
D:\a\1\s\packs\Helpers\Helpers.csproj : warning NU1903: Package 'System.Text.Json' 8.0.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-hh2w-p6rv-4g7w [D:\a\1\s\apps\ConsoleApp\ConsoleApp.csproj]
  Restored D:\a\1\s\packs\Helpers\Helpers.csproj (in 31.32 sec).
D:\a\1\s\packs\SpinCandidates\SpinCandidates.csproj : warning NU1903: Package 'Microsoft.Extensions.Caching.Memory' 8.0.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-qj66-m88j-hmgj [D:\a\1\s\apps\ConsoleApp\ConsoleApp.csproj]
D:\a\1\s\packs\SpinCandidates\SpinCandidates.csproj : warning NU1903: Package 'System.Text.Json' 8.0.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-8g4q-xg66-9fp4 [D:\a\1\s\apps\ConsoleApp\ConsoleApp.csproj]
D:\a\1\s\packs\SpinCandidates\SpinCandidates.csproj : warning NU1903: Package 'System.Text.Json' 8.0.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-hh2w-p6rv-4g7w [D:\a\1\s\apps\ConsoleApp\ConsoleApp.csproj]
D:\a\1\s\packs\SpinCandidates\SpinCandidates.csproj : warning NU1903: Package 'System.Text.RegularExpressions' 4.3.0 has a known high severity vulnerability, https://github.com/advisories/GHSA-cmhx-cq75-c4mj [D:\a\1\s\apps\ConsoleApp\ConsoleApp.csproj]
  Restored D:\a\1\s\packs\SpinCandidates\SpinCandidates.csproj (in 32.63 sec).

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 24.04
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022

Image version and build link

20241113.3.0

Is it regression?

20241021.1.0

Expected behavior

Using the same code base and same nuget versions, builds should not raise a different amount of build warnings depending on the used image version.

Actual behavior

When scheduled on an agent with version 20241113.3.0 we're seeing build warnings that we don't see on version 20241021.1.0

Repro steps

Build a .NET 8 project.

[lakshminarayana02]

Hi
we have been observing warning messages and working on them to resolve.

[mungojam]

That's to be expected as it added .net 9. The .net 9 SDK now checks for vulnerabilities in transitive dependencies as well as direct ones. You can override that behaviour, or else go with it and sort out the dependencies.

This noise is gradually reducing as various Microsoft packages are getting fixed so that they don't have direct dependencies on runtime-provided packages like System.Text.Json

[ptemmer]

Thanks for your the input Mark. However, why is it using the .net 9 SDK when our project is targeting .net 8?

[mungojam]

Thanks for your the input Mark. However, why is it using the .net 9 SDK when our project is targeting .net 8?

The runtime and SDK are quite independent. It will use the last installed SDK by default, but can then build for the .net 8 runtime just fine.

[ptemmer]

Yes indeed. I managed to work around the issue by specifically pointing to the .net8 tooling in the pipeline