[Eng] BCL Dependency Update to 10.x

[jsquire]

Summary

The focus of these changes is to update the .NET BCL dependency packages to the 10.x line.

As part of this work, the central package version configuration is also being cleaned up and refactored for clarity, to reduce duplication, and to trim unused entries. Additionally, some sections were reordered and references grouped for clarity. Comments were added to more clearly guide maintainers on how to manage dependencies over time, and offer guidance
for ensuring new dependencies are properly approved.

Also included:

• Extracting common version properties for packages intentionally used in limited scopes so that they use a consistent version.

• Removed restrictions on the general T2 dependencies, allowing them to be used by shipping libraries, tests, samples, and support projects. This eliminates the need for duplicate entries, while still allowing non-shipping dependencies to be explicitly declared.

• Removed unnecessary direct references from packages, preferring to rely on transitive dependencies from Azure.Core, System.ClientModel, and other primary packages. This reduces conflict for version upgrades.

• Removed VersionOverride attributes from projects where they were not used to fix temporary compatibility problems. Dependencies specific to a library have been constrained to a scoped central entry.

• Normalized the repository on the stable System.CommandLine package, replacing the previous beta. Refactored samples to adopt the stable API.

• Removed the ACR performance project, as it was not in active use and required references to retired and deprecated packages. There was no justification to spend the resources to update.

[Copilot]

Pull request overview

This PR updates .NET BCL dependency packages from 8.x to the 10.x line and refactors the central package version management for improved clarity and consistency.

Key changes:

• Updates BCL packages (Microsoft.Extensions., System., etc.) to version 10.x
• Migrates from beta System.CommandLine (2.0.0-beta1) to stable version 2.0.1
• Removes unnecessary direct package references, relying on transitive dependencies
• Removes ACR performance project due to deprecated dependencies

Reviewed changes

Copilot reviewed 107 out of 109 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
eng/Packages.Data.props	Major refactor: adds version properties, reorganizes sections, updates BCL to 10.x
eng/Directory.Build.Common.targets	Simplifies API compat baseline logic, adds System.Linq.AsyncEnumerable exclusion
sdk/keyvault/samples/getcert/Program.cs	Migrates to stable System.CommandLine API with typos in option names
sdk/keyvault/samples/sharelink/Program.cs	Migrates to stable System.CommandLine API
sdk/servicebus/Azure.Messaging.ServiceBus/samples/*/Program.cs	Updates System.CommandLine usage to stable API
sdk/ai/Azure.AI.VoiceLive/samples/*/SampleProgram.cs	Updates System.CommandLine usage with formatting issue
sdk/containerregistry/Azure.Containers.ContainerRegistry/tests/Infrastructure/*.cs	New test utility files with double BOM encoding
sdk/containerregistry/Azure.Containers.ContainerRegistry/perf/*	Removes ACR performance project and dependencies
Multiple *.csproj files	Removes VersionOverride, transitive dependencies, and normalizes formatting

[eerhardt]

Was it intentional that this lifts the System.Text.Json (and other shared fx assemblies like Microsoft.Extensions.*.Abstractions) reference to version 10.0 for all TFMs - including net8.0? This means any net8.0 application referencing Azure.Core will use the v10 System.Text.Json, which means that assembly will ship along side the application instead of being loaded from the shared framework.

We've had this discussion a few times on our team. We also have dotnet/docs#49958 to try to add guidance in this area.

I'm not saying this is a critical issue. I just want to be sure this is intentional, as it has downstream effects on libraries and applications.

cc @ericstj

[jsquire]

@eerhardt: Yes. Per the Azure SDK for .NET Guidelines, BCL dependencies will move to the latest LTS line when a new version of .NET is released. We do not maintain separate major version lines and conditionalizing versions per target was deemed to be more risk/cost than the benefits that it provided. Happy to talk further and gather additional perspective.

(Since you copied Eric, this is something that he and I had discussed around the September timeframe when MEAI was considering dependencies, and several times earlier when we adapted our previous "use the oldest dependency possible" approach.)

[m-redding]

@eerhardt @jsquire STJ is removed from dependencies on net8.0 and net10.0 targets, deferring to the shared framework version.

https://www.nuget.org/packages/Azure.Core#dependencies-body-tab

[jsquire]

@eerhardt @jsquire STJ is removed from dependencies on net8.0 and net10.0 targets, deferring to the shared framework version.

Thanks, @m-redding. I forgot about that!

[eerhardt]

STJ is removed from dependencies on net8.0

2 things:

1. System.Memory.Data v10 brings in System.Text.Json v10, so it comes in transitively.
2. Removing that dependency on net8.0 is incorrect and can lead to issues. The problem is that the netstandard2.0 TFM brings in the System.Text.Json v10 dependency, so you can use v10 APIs in your code. If net8.0 doesn't depend on System.Text.Json v10, apps that target net8.0 can get MissingMethodExceptions because it uses the STJ in the shared framework, which doesn't have the new APIs.
   • In this case you might be saved by (1) because System.Memory.Data is doing it correctly:

But, in general, excluding the dependency on the lower TFM will lead to problems.

[m-redding]

you can use v10 APIs in your code

I would expect that the build would fail on the .NET 8 target if we tried to use a .NET 10 API. We usually mitigate issues like that with preprocessor directives

[eerhardt]

It's a "next level" dependency problem. Imagine another library that only targets netstandard2.0 and references Azure.Core. That library sees STJ v10 and can use new v10 APIs.

They ship their netstandard2.0 library in a NuGet package.

Now an app targeting net8.0 uses that library, nothing would bring in System.Text.Json v10.

In this specific case System.Memory.Data is probably saving us since it would bring in STJ v10.

But this is a general issue:

[m-redding]

Opened an issue to track - #55566