Upgrade System.Memory to 4.6.0

[mthalman]

Using a recent daily build of .NET 10 SDK to source build the arcade repo causes the following errors:

/__w/1/vmr/src/arcade/src/VersionTools/Microsoft.DotNet.VersionTools/Microsoft.DotNet.VersionTools.csproj error NU1605: Warning As Error: Detected package downgrade: System.Memory from 4.6.0 to 4.5.5. Reference the package directly from the project to select a different version. 
 Microsoft.DotNet.VersionTools -> System.Formats.Asn1 10.0.0-alpha.1.24610.2 -> System.Memory (>= 4.6.0) 
 Microsoft.DotNet.VersionTools -> NuGet.Packaging 6.11.0 -> System.Security.Cryptography.Pkcs 6.0.4 -> System.Memory (>= 4.5.5) [/__w/1/vmr/src/arcade/Arcade.sln]
/__w/1/vmr/src/arcade/src/Common/Microsoft.Arcade.Common/Microsoft.Arcade.Common.csproj error NU1605: Warning As Error: Detected package downgrade: System.Memory from 4.6.0 to 4.5.5. Reference the package directly from the project to select a different version. 
 Microsoft.Arcade.Common -> System.Collections.Immutable 10.0.0-alpha.1.24610.2 -> System.Memory (>= 4.6.0) 
 Microsoft.Arcade.Common -> Microsoft.Build.Utilities.Core 17.8.3 -> System.Memory (>= 4.5.5) [/__w/1/vmr/src/arcade/Arcade.sln]
/__w/1/vmr/src/arcade/src/Microsoft.DotNet.GenFacades/Microsoft.DotNet.GenFacades.csproj error NU1109: Detected package downgrade: System.Memory from 4.6.0 to centrally defined 4.5.5. Update the centrally managed package version to a higher version. 
 Microsoft.DotNet.GenFacades -> Microsoft.CodeAnalysis.CSharp 4.13.0-2.24561.1 -> System.Memory (>= 4.6.0) 
 Microsoft.DotNet.GenFacades -> System.Memory (>= 4.5.5) [/__w/1/vmr/src/arcade/Arcade.sln]

Resolving this by upgrading to 4.6.0.

[ViktorHofer]

I added the Bcl.HashCode update as well (these packages got produced together at once from maintenance-packages so it makes sense to keep them in sync).

[ViktorHofer]

Unfortunately, I need to request changes. I just noticed that the System.Memory update impacts .NET Framework msbuild tasks. VS desktop msbuild doesn't yet have those never versions available inbox. We had to approach this differently: https://github.com/dotnet/msbuild/blob/a71903d9684e24db3db261b27ca73c0ef879cf81/eng/Versions.props#L26-L40

This doesn't cause any failures here as the msbuild tasks aren't tested inside a desktop msbuild environment.

Can you please update this change to only update those versions when building from source with a tracking issue to consolidate eventually? cc @carlossanlop @ericstj

[mthalman]

@ViktorHofer - Do you know if the same condition is needed for fsharp: dotnet/fsharp#18166?

[ViktorHofer]

Do you know if the same condition is needed for fsharp: dotnet/fsharp#18166?

Only for msbuild tasks that are executed on desktop msbuild. I don't think that's the case for fsharp so the change should be good.

[ViktorHofer]

I think the Bcl.HashCode one also needs the conditional update as the Microsoft.DotNet.Build.Tasks.Feed library (which uses that package) is used in a desktop msbuild environment. Please make the same change for it as well.

The rule is that any library that ships inbox in desktop msbuild and is used by an msbuild task either directly or transitively must not go higher than what is provided inbox.

[mthalman]

I think the Bcl.HashCode one also needs the conditional update as the Microsoft.DotNet.Build.Tasks.Feed library (which uses that package) is used in a desktop msbuild environment. Please make the same change for it as well.

The rule is that any library that ships inbox in desktop msbuild and is used by an msbuild task either directly or transitively must not go higher than what is provided inbox.

What part of source build requires a newer version of Microsoft.Bcl.HashCode?

[ViktorHofer]

Good point, no component here in arcade. I'll revert the version upgrade as it's problematic with desktop msbuild.

EDIT: GH wrote the commit description, no idea why it mentioned BuildTask.props.