[release/3.1] Should we unpin a couple of packages?

[dougbu]

The following packages are pinned in dotnet/extensions, dotnet/efcore, and dotnet/aspnetcore at non-*.0 versions

• System.IO.Pipelines
• System.Runtime.CompilerServices.Unsafe

The more important of these is likely System.IO.Pipelines because it's pinned at 4.7.1 though 4.7.2 exists and it's in Microsoft.AspNetCore.App.Runtime.* packages.

See discussion at https://github.com/dotnet/extensions/pull/3408/files/0124e2f14b1a413bb11555c16f08b62444f459d7#diff-5c6a1c77fe216efcfbbdccb11b863063

---

Somewhat separately, the following packages are currently pinned in dotnet/aspnetcore at *.0 versions even though that repo auto-downgrades what we compile against and ensures we place the *.0 assembly versions in our ref/ pack. Should we let the references float so we're testing against the latest implementation assemblies❔ Would only need to add then to the auto-downgrade list if we went this way.

• Microsoft.Win32.Registry
• System.Security.Cryptography.Cng
• System.Security.Principal.Windows

[dougbu]

/fyi other than System.IO.Pipelines we're currently pinned at the latest 3.1 versions of these packages

[dougbu]

/cc @dotnet/aspnet-build

[wtgodbe]

I'm in favor of unpinning just System.IO.Pipelines & System.Runtime.CompilerServices.Unsafe (and adding them to repos below us). Keeping the other 3 pinned more accurately represents what we use them for - I'd forgotten the reason until I went back and looked through those old PRs & issues.

[dougbu]

I lean the same way @wtgodbe but would add "… for now" 😺

The last three dependencies are not just treated as compilation only. They're odd ducks, part of Microsoft.NETCore.App but not Microsoft.NETCore.App.Ref. We have a few direct references to them all, likely to get the ref/ assemblies and for testing. It's the testing part I worry about. If any of these rev in servicing, we won't be testing against the latest versions. This will likely matter more after we bump up the .NET Framework assembly count. Not urgent but is something to keep in mind.

• Microsoft.Win32.Registry references (ignoring ref/ projects) include:
  • src\DataProtection\DataProtection\src\Microsoft.AspNetCore.DataProtection.csproj
  • src\Servers\HttpSys\src\Microsoft.AspNetCore.Server.HttpSys.csproj
  • src\Tools\Microsoft.dotnet-openapi\src\Microsoft.dotnet-openapi.csproj
• System.Security.Cryptography.Cng is in a similar place though it shows up in fewer test and test asset bin/ folders than the other two. References to it are in:
  • src\Servers\Kestrel\Core\src\Microsoft.AspNetCore.Server.Kestrel.Core.csproj
  • src\Tools\dotnet-dev-certs\src\dotnet-dev-certs.csproj
• System.Security.Principal.Windows references include:
  • src\DataProtection\DataProtection\src\Microsoft.AspNetCore.DataProtection.csproj
  • src\Servers\HttpSys\src\Microsoft.AspNetCore.Server.HttpSys.csproj
  • src\Servers\IIS\IIS\src\Microsoft.AspNetCore.Server.IIS.csproj
  • src\Servers\IIS\IISIntegration\src\Microsoft.AspNetCore.Server.IISIntegration.csproj
  • src\Shared\test\Shared.Tests\Microsoft.AspNetCore.Shared.Tests.csproj
  • src\SignalR\common\Http.Connections\src\Microsoft.AspNetCore.Http.Connections.csproj
  • src\Tools\Microsoft.dotnet-openapi\src\Microsoft.dotnet-openapi.csproj

[dougbu]

Done w/ this. Fixes were spread across the commits listed above. In particular:

• dotnet/extensions@a741555
• dotnet/razor@7f7b08f
• dotnet/efcore@23cd9c4
• ffdec02