-
Notifications
You must be signed in to change notification settings - Fork 763
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/arcade dotnet/roslyn dotnet/runtime #3077
[master] Update dependencies from dotnet/arcade dotnet/roslyn dotnet/runtime #3077
Conversation
…0309.13 - NETStandard.Library.Ref - 2.1.0-preview.3.20159.13 - Microsoft.NETCore.App.Runtime.win-x64 - 5.0.0-preview.3.20159.13 - Microsoft.NETCore.App.Ref - 5.0.0-preview.3.20159.13 - Microsoft.NETCore.App.Internal - 5.0.0-preview.3.20159.13 Dependency coherency updates - Microsoft.Win32.Registry - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64) - System.ComponentModel.Annotations - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64) - System.Diagnostics.DiagnosticSource - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64) - System.Diagnostics.EventLog - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64) - System.IO.Pipelines - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64) - System.Reflection.Metadata - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64) - System.Runtime.CompilerServices.Unsafe - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64) - System.Security.Cryptography.Cng - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64) - System.Security.Cryptography.Xml - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64) - System.ServiceProcess.ServiceController - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64) - System.Text.Encodings.Web - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64) - System.Text.Json - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64) - Microsoft.NETCore.Platforms - 5.0.0-preview.3.20159.13 (parent: Microsoft.NETCore.App.Runtime.win-x64)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Auto-approving dependency update.
This comment has been minimized.
This comment has been minimized.
@dagood this error message showed up again:
Previous discussions here: dotnet/runtime#1129. |
This comment has been minimized.
This comment has been minimized.
To sum up, if it's the same issue, I would expect to see a There are some "odd" names in the manifest with @dotnet/runtime-infrastructure PTAL, I might be missing context on recent changes and it might be one of the other causes listed in that issue that I'm not very familiar with anyway (openssl version etc.) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
-4305 is kCCUnimplemented (https://opensource.apple.com/source/CommonCrypto/CommonCrypto-36064/CommonCrypto/CommonCryptor.h.auto.html). The last time we had a problem with that was fixed in 2017. Maybe something is being weird in library binding and we're finding an old copy? Is there a good way to figure out where our shim got loaded from on the CI machines? AESKeyWrapEncrypt /does/ use ECB mode, so it /could/ be the problems that we fixed in dotnet/corefx#21631 ... if we're finding an old version of the library. |
This comment has been minimized.
This comment has been minimized.
We fairly recently changed the OS version for the MacOS version. @dougbu would have more specifics about it. Could that affect this in any way? |
This comment has been minimized.
This comment has been minimized.
We recently changed the name of the native libraries. Is it possible that the because of the name change and the fact that we are relying on probing to find libSystem.Security.Cryptography.Native.so when it didn’t find System.Security.Cryptography.Native.so that we’re picking up an old version of System.Security.Crpytography.Native.so? |
This comment has been minimized.
This comment has been minimized.
If you bumped to 10.15, yes (I don't think dotnet/runtime has that in CI yet because the images weren't ready/reliable). If you're 10.14 then the most likely culprit is the shim library rename, since that would be something you'd probably just now be ingesting (and dotnet/runtime isn't failing on 10.14). |
We're on 10.14 now |
This comment has been minimized.
This comment has been minimized.
That seems like a possible issue. I think the easiest would be to pull this and debug locally. Trying now to see what System.Security.Cryptography.Native.so it is loading. |
This comment has been minimized.
This comment has been minimized.
Agreed with the assesment of @jkoritzinsky and @safern. In 1.x we shipped nuget packages with these shims and rely on conflict resolution to make the framework copies win. To avoid those old versions of System.Native.* from 1.x you can just reference the latest Microsoft.NETCore.Targets which dummys out all the old runtime.json that brought in the RID-specific System.Native packages. |
This comment has been minimized.
This comment has been minimized.
@ericstj is that a recommendation for this project https://github.com/dotnet/extensions/blob/master/src/Configuration/Config.Xml/src/Microsoft.Extensions.Configuration.Xml.csproj#L19 or for the System.Security.Cryptography.Xml package? |
This comment has been minimized.
This comment has been minimized.
Not exactly. The only way you'd get an old System.Native.* is if you had a reference to a 1.x era package. You'd need to find out which project was bringing that in and add the reference there. System.Security.Cryptography.Xml wouldn't be the culprit, it's probably some 3rd party package with very old dependencies. |
This comment has been minimized.
This comment has been minimized.
Oh, could be - we see transient failures w/ |
This comment has been minimized.
This comment has been minimized.
Windows failures are gone on the second attempt, but we still have:
And:
Which is the same error as before... |
This comment has been minimized.
This comment has been minimized.
No, those are gone on the second attempt. You're looking at the test tab which will show failures across all retries. @ericstj @safern Could we get some help with the crypto errors that haven't gone away with the Runtime fix? |
This comment has been minimized.
This comment has been minimized.
We had discussed that we'll hold off on consuming the extensions from dotnet/runtime to avoid too much churn. @JunTaoLuo can you peel-off the consumption of extensions into a seperate PR so that it doesn't block ingestion of runtime? |
This comment has been minimized.
This comment has been minimized.
I'm not aware of us consuming Extensions from Runtime anywhere yet. Am I missing something here? |
This comment has been minimized.
This comment has been minimized.
Right you are, sorry Nevermind, just me, crossed wires. Let me look at crypto failures. |
This comment has been minimized.
This comment has been minimized.
Here's what I see in the binlog. The following is referenced by the test project: Native shim references
PackageOverrides
So the problem is that the PackageOverrides.txt file defined by the shared framework is not being used by the SDK /cc @dsplaisted @dagood Will keep looking for root cause of that and a workaround. |
This comment has been minimized.
This comment has been minimized.
Ok, it looks like the new info is read, but is garbled. The |
This comment has been minimized.
This comment has been minimized.
Opened the bug here: dotnet/sdk#10904 To workaround you can run a target that fixes it, stay tuned and will share that. |
This comment has been minimized.
This comment has been minimized.
Ok, I tried to workaround the PackageOverride reading bug, but then encountered another issue, so reactivated dotnet/runtime#33450 So I took another tactic at fixing this: just avoiding the reference to the 1.x era packages. I found these were coming in transitively from a number of packages (Moq, xunit, etc) which reference NETStandard.Library 1.6.0. This is issue dotnet/sdk#3044. I'll workaround it by updating that transitive reference. |
This comment has been minimized.
This comment has been minimized.
Edit: I see everyone has already figured this out, sorry for the spam |
Workaround issue where packages transitively bring in 1.x era packages.
Auto-Merge StatusThis pull request will be merged because the following merge policies have succeeded.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @ericstj
🎉 |
This pull request updates the following dependencies
From https://github.com/dotnet/runtime
Coherency Updates
The following updates ensure that dependencies with a CoherentParentDependency
attribute were produced in a build used as input to the parent dependency's build.
See Dependency Description Format
From https://github.com/dotnet/roslyn
From https://github.com/dotnet/arcade