Pin the System.Memory package reference version in Microsoft.Extensions.DependencyModel

[carlossanlop]

Needed to address the failure found in the runtime deps flow dotnet/sdk#48034

This will be done alongside the proper update in S.R.CS.Unsfae: dotnet/maintenance-packages#221

I will generate a patch for the deps flow as well.

[Copilot]

Copilot wasn't able to review any files in this pull request.

Files not reviewed (1)

• src/libraries/Microsoft.Extensions.DependencyModel/src/Microsoft.Extensions.DependencyModel.csproj: Language not supported

[carlossanlop]

I need to address the detected package downgrade error:

C:\Users\calope\source\repos\runtime\src\libraries\Microsoft.Extensions.DependencyModel\src\Microsoft.Extensions.DependencyModel.csproj : error NU1605: Warning As Error: Detected package downgrade: System.
Memory from 4.6.2 to 4.6.1. Reference the package directly from the project to select a different version.  [C:\Users\calope\source\repos\runtime\Build.proj]

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[ericstj]

We can consider this as an option - on the pro side it stands to help reduce the dependencies redistributed in the SDK. For this to actually eliminate those we would need every assembly in the SDK tasks to follow this. I'm not sure how tractable this is - today the set of assemblies used by SDK tasks from latest runtime are:

• Microsoft.NET.HostModel
• Microsoft.Extensions.DependencyModel
• System.Text.Json
• System.IO.Hashing
• System.IO.Pipelines
• System.Text.Encodings.Web
• Microsoft.Bcl.AsyncInterfaces

So for all System.Text.Json, System.Text.Encodings.Web, and Microsoft.Bcl.AsyncInterfaces -- we could use the toolset versions in all these components. That would mean no new features - but it might be OK for SDK tasks.
HostModel and DependencyModel are design time focused assemblies - so we could make the case for those staying on toolset version packages.
System.IO.Pipelines is brought in by STJ so that can be ignored.
IO.Hashing is used by SDK tasks directly - it also depends on Memory and Unsafe - so it might still be a problem even if we fix the others.

@dsplaisted

[ericstj]

Source build is failing due to downgrades. Probably every toolset package version would need to be overidden like this

runtime/Directory.Build.targets

Lines 99 to 100 in 4370474

	<SystemReflectionMetadataLoadContextToolsetVersion Condition="'$(DotNetBuildSourceOnly)' == 'true'">$(SystemReflectionMetadataLoadContextVersion)</SystemReflectionMetadataLoadContextToolsetVersion>
	<SystemTextJsonToolsetVersion Condition="'$(DotNetBuildSourceOnly)' == 'true'">$(SystemTextJsonVersion)</SystemTextJsonToolsetVersion>

That said, I'm not sure if we can pursue this approach right now because of #114173 (comment).

We might just want to drive the new System.Memory package in.

[ViktorHofer]

This is essentially NetToolMinimum: https://github.com/dotnet/arcade/blob/63c161539bde4a68f27bc66598137da578331d85/src/Microsoft.DotNet.Arcade.Sdk/tools/TargetFrameworkDefaults.props#L37-L40

We added the NetTool* properties for the VS constraint.

[ericstj]

I wondered if we already had it somewhere. Let's hold off on changing this PR and burning more build resources until we understand what direction we want to take. I'm not sure if this one is going to pan out.

[carlossanlop]

I'll close it for the time being. My understanding is that we're not going to take this at the moment. We can always reopen if we change our minds.