-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[master] Update dependencies from dotnet/runtime #14574
[master] Update dependencies from dotnet/runtime #14574
Conversation
…1117.3 Microsoft.NETCore.Platforms , System.CodeDom , Microsoft.NET.HostModel , Microsoft.Extensions.DependencyModel , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.DotNetHostResolver , Microsoft.NETCore.App.Ref , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.6.0 From Version 6.0.0-alpha.1.20560.10 -> To Version 6.0.0-alpha.1.20567.3
…1117.4 Microsoft.NETCore.Platforms , System.CodeDom , Microsoft.NET.HostModel , Microsoft.Extensions.DependencyModel , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.DotNetHostResolver , Microsoft.NETCore.App.Ref , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.6.0 From Version 6.0.0-alpha.1.20560.10 -> To Version 6.0.0-alpha.1.20567.4
…1117.16 Microsoft.NETCore.Platforms , System.CodeDom , Microsoft.NET.HostModel , Microsoft.Extensions.DependencyModel , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.DotNetHostResolver , Microsoft.NETCore.App.Ref , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.6.0 From Version 6.0.0-alpha.1.20560.10 -> To Version 6.0.0-alpha.1.20567.16
|
…1118.2 Microsoft.NETCore.Platforms , System.CodeDom , Microsoft.NET.HostModel , Microsoft.Extensions.DependencyModel , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.DotNetHostResolver , Microsoft.NETCore.App.Ref , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.6.0 From Version 6.0.0-alpha.1.20560.10 -> To Version 6.0.0-alpha.1.20568.2
@jkoritzinsky any idea why the DotNetAppHost package is missing? |
@ViktorHofer @jkoritzinsky It was removed here dotnet/runtime@a505c46 /cc @Anipik |
At least, I'm pretty sure. It's in this build: https://dev.azure.com/dnceng/internal/_build/results?buildId=884890&view=artifacts&type=publishedArtifacts but not this one https://dev.azure.com/dnceng/internal/_build/results?buildId=885334&view=artifacts&type=publishedArtifacts |
That was unintentional. I thought I kept all of the legacy host packages. Apparently accidentally dropped one. I’ll add it back. |
When you say legacy package, do you mean that dotnet/sdk should use another one ideally? |
By legacy I mean a package that used to be used in product construction before .NET Core 3.0. If the SDK still has a usage for the packages, then they’re the right ones to use. |
…1118.7 Microsoft.NETCore.Platforms , Microsoft.NET.HostModel , Microsoft.Extensions.DependencyModel , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.DotNetHostResolver , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.App.Ref , System.CodeDom , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.6.0 From Version 6.0.0-alpha.1.20560.10 -> To Version 6.0.0-alpha.1.20568.7
Do we need to update the System.Text.Json version being used in the sdk?
|
cc: @dsplaisted |
…1119.2 Microsoft.NETCore.Platforms , Microsoft.NET.HostModel , Microsoft.Extensions.DependencyModel , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.DotNetHostResolver , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.App.Ref , System.CodeDom , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.6.0 From Version 6.0.0-alpha.1.20560.10 -> To Version 6.0.0-alpha.1.20569.2
In 5.0.0 Microsoft.Extensions.DependencyModel depended on System.Text.Json 5.0.0: In 6.0 it depends on the 6.0.0 version. |
Yeah, as @ericstj explained by default in dotnet/runtime repo all dependencies between live-built packages are to the live-built version (latest version) after a re-baseline of the repo, which we do after every big release. That means that now that we have switched dotnet/runtime repo to target 6.0, we have re-baselined all live-built packages to use 6.0.0 as well. |
The restore failure is happening when the TargetFramework for the project is <group targetFramework="net5.0" /> The new package doesn't have this group, so NuGet ends up selecting the This seems like an unintentional change and it is breaking us. @ericstj / @joperezr Can you investigate this change or find the right person to do so? Thanks! |
Indeed I can see this here: https://www.nuget.org/packages/Microsoft.Extensions.DependencyModel/ This is controlled by the inboxOn calculations by the packaging system to drop the package references where these are inbox. @Anipik we need to add inbox here (and likely others) for 6.0.0: https://github.com/dotnet/runtime/blob/2e8c4c78d5dc628afd94053a008ab203e648a2b9/src/libraries/pkg/baseline/packageIndex.json#L6629 @dsplaisted why would you be referencing System.Text.Json package at all on sdk/src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/Microsoft.DotNet.MSBuildSdkResolver.csproj Line 84 in d257737
You could do that to unblock yourself here. |
No, but the subscription can be disabled in the interim. |
I will look as soon as I'm out of meetings today, if nobody does ahead of time. It would be surprising if something so basic broke; I don't see any relevant recent changes in a quick look. |
@danmosemsft I created a simple repro: static void Main(string[] args)
{
foreach (var subdir in new DirectoryInfo(args[0]).GetDirectories())
{
Console.WriteLine(subdir.FullName);
}
} I get different output between .NET 5 and .NET 6 (Shared Framework 6.0.0-alpha.1.20614.10). .NET 5:
.NET 6
|
Looking at that now. |
I have a suspicion that the |
As @eerhardt pointed out - here's the repro:
|
Should we be running unit tests against crossgenned bits? As far as I can see, this would break the unit tests. |
For libraries we don't today as we don't crossgen in the libraries build but in the installer. Kind of tracked via dotnet/runtime#487 |
Right, it's come up several times. This would essentially be a move to catch crossgen, not libraries bugs - so I think @mangod9 would be the best person to decide what the priority should be. In this case, we were fortunate that SDK tests found it -- as far as I know the bits we ship to customers never have the libraries teams' tests run on them at all. |
Correct, we don't run automated tests for official builds.
We might want to do it sooner or later anyway as it reduces complexity and duplication of our test bootstrapping logic. @jkoritzinsky and I were looking at using the bundle that currently lives in the installer subset of dotnet/runtime for that. |
My vote would be sooner rather than later as upstack tests probably only verify 10% of what our unit tests do (since it's not their job) - it feels like we are relying on previews to discover such bugs, and we want previews to be more predictable. |
Absolutely agree. Will make sure that this item is prioritized accordingly. |
+@trylek, who will soon be working on compiling libraries using cg2. Would be good to ensure that we can run library tests on compiled bits. Thx. |
As for the |
No, it appears only to repro on Mac and Linux |
I looked at this to narrow down when things broke, and it appears possibly related to this change: dotnet/runtime#45625. Looks to have been rolled back recently since it was causing other failures as part of this PR: dotnet/runtime#46172 this is possibly the cause:
@jkoritzinsky possibly this should wait till we get cg2 rolled out broadly ? |
@jkotas fyi |
…1216.14 Microsoft.NETCore.Platforms , Microsoft.NETCore.DotNetHostResolver , Microsoft.NET.HostModel , Microsoft.Extensions.DependencyModel , Microsoft.NETCore.App.Runtime.win-x64 , Microsoft.NETCore.App.Host.win-x64 , Microsoft.NETCore.App.Ref , System.CodeDom , System.Reflection.MetadataLoadContext , System.Resources.Extensions , System.Security.Cryptography.ProtectedData , System.Text.Encoding.CodePages , VS.Redist.Common.NetCore.SharedFramework.x64.6.0 From Version 6.0.0-alpha.1.20560.10 -> To Version 6.0.0-alpha.1.20616.14
This is not common. There are number of other less common cases that cg2 handles better than cg1. One more or less won't make a huge difference. I think this is fine. |
@mangod9 @jkoritzinsky what is our plan to get this addressed? Are we going to take the latest runtime which contains the revert? |
The latest runtime bump from about three hours ago already contains the fix: dotnet/runtime#46176 |
Yeah build |
It passed CI and merged! 🎉🎉🎉 Thanks folks. |
@marek-safar @jeffschwMSFT...tag! Which of you takes the next one. |
I can be it. Given the holidays, it will likely be early next year. :) |
This pull request updates the following dependencies
From https://github.com/dotnet/runtime