Bump versions of maintenance-packages dependencies consumed in runtime

[carlossanlop]

dotnet/runtime depends on these packages that we are now publishing from dotnet/maintenance-packages:

• Microsoft.Bcl.HashCode
• System.Buffers
• System.Memory
• System.Threading.Tasks.Extensions
• System.Runtime.CompilerServices.Unsafe

Bumping their versions to consume the new preview versions, available in the dotnet-libraries feed: https://dnceng.visualstudio.com/public/_artifacts/feed/dotnet-libraries

Related PRs:

• machinelearning: Bump versions of maintenance-packages dependencies consumed in runtime #108806
• winforms: Bump version of System.Runtime.CompilerServices.Unsafe to preview coming from maintenance-packages winforms#12313

[dotnet-policy-service]

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

[carlossanlop]

There's a CI failure indicating that a triple slash cref pointing to MathF is ambiguous. I see that the updated System.Numerics.Vectors OOB package defines MathF but it is an internal class there. I don't see how it could be conflicting.

[carlossanlop]

@ericstj @michaelgsharp @ViktorHofer I don't think the problem is in the package. When comparing the DLLs with ILSpy, before and after maintenance-packages, they all contain the MathF class and it's internal. So I don't know what could be causing the cref conflict.

The old nupkg:

• net462
  
• netstandard2.0
  

The new preview nupkg:

• net462:
  
• netstandard2.0:
  

[ericstj]

The old package contained a reference assembly, which didn't include the internal MathF type. That's why the new package is hitting this. The new package only exposes the implementation, which has the internal type. This is issue dotnet/roslyn#71442.

We can workaround it by aliasing the problematic assembly, and then referring to it by the alias. I'll submit a fix.

Another way to fix this would be to put the internal MathF type in a different namespace, but I don't think we need to do that. I doubt customers will hit this bug.

[carlossanlop]

Thanks for the fix @ericstj

I doubt customers will hit this bug

So there's no way a customer will do what Tensors is doing? Is Tensors special and unique enough because of the way runtime works and consumes the package?

[carlossanlop]

@MichaelSimons what specific thing abouy these nupkgs is considered a prebuilt?
We are hitting this error:

error : 6 new pre-builts discovered! 
Detailed usage report can be found at /__w/1/s/artifacts/sb/prebuilt-report/baseline-comparison.xml. 
See https://aka.ms/dotnet/prebuilts for guidance on what pre-builts are and how to eliminate them. 
Package IDs are: 
Microsoft.Bcl.HashCode.6.0.0-preview.1.24517.1 
System.Buffers.4.6.0-preview.1.24517.1 
System.Memory.4.6.0-preview.1.24517.1 
System.Numerics.Vectors.4.6.0-preview.1.24517.1 
System.Runtime.CompilerServices.Unsafe.6.1.0-preview.1.24517.1 
System.Threading.Tasks.Extensions.4.6.0-preview.1.24517.1

[ericstj]

So there's no way a customer will do what Tensors is doing?

It's not impossible, just unlikely for a customer to cref MathF from their doc comments.

what specific thing about these nupkgs is considered a prebuilt?

They're built from a repo that's not part of source build yet, and they aren't provided by SBRP. Maybe we should bring maintenance-packages into source build @MichaelSimons. In the meantime I think we can mark these as permitted prebuilts.

[MichaelSimons]

They're built from a repo that's not part of source build yet, and they aren't provided by SBRP. Maybe we should bring maintenance-packages into source build @MichaelSimons. In the meantime I think we can mark these as permitted prebuilts.

If you do this the runtime flow will fail in the sdk repo until the dotnet/maintenance-packages repo is onboarded onto SB. If you don't want to block the flow I would wait merging this PR until you have onboarded dotnet/maintenance-packages into source-build.

[carlossanlop]

Bump the versions to the preview used in SBRP.

[carlossanlop]

I'll address the conflict after I merge #109390 which unblocks this PR (so that I don't restart the CI unnecessarily).

[carlossanlop]

@ViktorHofer I updated this PR to also consume the new System.Data.SqlClient prerelease version and there's an ApiCompat failure that makes sense: The old package used to contain a netcoreapp2.1 folder, but the new package contains a net6.0 and a net8.0 folder.

Is this failure expected and supressable, or should we add a placeholder for netcoreapp2.1 in System.Data.SqlClient? (My gut says expected).

src/libraries/apicompat/ApiCompat.proj(93,5): error MSB4018: (NETCORE_ENGINEERING_TELEMETRY=Build) The "Microsoft.DotNet.ApiCompat.Task.ValidateAssembliesTask" task failed unexpectedly.
System.IO.DirectoryNotFoundException: Could not find a part of the path '/__w/1/s/.packages/system.data.sqlclient/4.9.0-rtm.24561.10/lib/netcoreapp2.1/System.Data.SqlClient.dll'.

[ViktorHofer]

This line needs an update: https://github.com/dotnet/runtime/blob/main/src%2Flibraries%2Fapicompat%2FApiCompat.proj#L46

The TFM

[carlossanlop]

@cheenamalhotra @David-Engel we're updating the SqlClient dependency in runtime to the latest. I suppose the warning is expected since it's now marked as obsolete. Should we suppress it or what do you suggest?

[David-Engel]

we're updating the SqlClient dependency in runtime to the latest. I suppose the warning is expected since it's now marked as obsolete. Should we suppress it or what do you suggest?

Suppress, IMO.

[cheenamalhotra]

@cheenamalhotra @David-Engel we're updating the SqlClient dependency in runtime to the latest. I suppose the warning is expected since it's now marked as obsolete. Should we suppress it or what do you suggest?

For tests, we can suppress.
But if its used as a product dependency, I'd recommend creating an issue to track migration to Microsoft.Data.SqlClient in future releases of .NET runtime.

[carlossanlop]

@cheenamalhotra @David-Engel I suppressed the warning in System.Data.Common.Tests.csproj with a comment reminding to remove the suppression after the migration to Microsoft.Data.SqlClient happens in the runtime repo.

I did not see the same warning show up in product code, only test code.

[carlossanlop]

Sigh. Source build once again complaining about prebuilts:

.packages/microsoft.dotnet.arcade.sdk/10.0.0-beta.24556.2/tools/SourceBuild/AfterSourceBuild.proj(81,5): error : (NETCORE_ENGINEERING_TELEMETRY=AfterSourceBuild) 6 new pre-builts discovered! Detailed usage report can be found at /__w/1/s/artifacts/sb/prebuilt-report/baseline-comparison.xml.
See https://aka.ms/dotnet/prebuilts for guidance on what pre-builts are and how to eliminate them.
Package IDs are:
Microsoft.Bcl.HashCode.6.0.0
System.Buffers.4.6.0
System.Memory.4.6.0
System.Numerics.Vectors.4.6.0
System.Runtime.CompilerServices.Unsafe.6.1.0
System.Threading.Tasks.Extensions.4.6.0

[carlossanlop]

The wasm failures are unrelated:

• [browser] Connection refused in 127.0.0.1 #104349
• A build process died because the machine got reset

[MichaelSimons]

Sigh. Source build once again complaining about prebuilts:

It looks like these need to be added to SBRP because of the update to use stable versions in ec8185f. This was the plan discussed in dotnet/maintenance-packages#140 (comment).

[carlossanlop]

It looks like these need to be added to SBRP

Here you go dotnet/source-build-reference-packages#1082

[carlossanlop]

Darc flow PR #110071