-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Update SDK to 6.0 RC2 #60256
Update SDK to 6.0 RC2 #60256
Conversation
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsUpdating the SDK now to see if there's anything that needs attention for dotnet/runtime to consume RC2 and the final 6.0 SDK later.
|
from https://github.com/dotnet/runtime/pull/60256/checks?check_run_id=3873792305. @steveisok I spoke with @akoeplinger offline and he mentioned that you are probably the right person to ask about why the samples try to restore a runtime pack as presumably they shouldn't and instead use the live built one later. |
@ericstj @Anipik FYI that the SDK upgrade causes the package testing to fail. Haven't yet looked into what's causing the duplicate assets. |
Looks like conflict resolution isn't picking the ref pack. I would expect dotnet/sdk@fb094f4 to have fixed this scenario, which was in RC2. |
Interesting, conflict resolution is working for the reference.
But not working for runtime, it doesn't drop the copy-local asset.
We later test runtime closure against the refpack (to avoid having to restore all runtimes) and that's what's failing. Looking at the call to conflict resolution, it's missing the PlatformManifest. If I compare a 6.0 TFM to the failing 7.0 they differ in this way. I don't see a platform manifest returned from the ResolveTargetingPackAssets task in the failing net7.0 project. Is it produced? |
dotnet/sdk@70f204b is new in rc2 which seems to be related. |
Yep, that looked suspicious to me too. cc @rainersigwald |
Yeah, looks fishy to me too. I'll investigate. Is it possible to (temporarily) hack the build script to set the environment variable |
Would you mind pointing me in the direction of which binlog you were looking at and what project was causing the problems? |
I wonder if MSBuild caches this information at a point before we've built things like the platform manifest and then never refreshes it later on. @ViktorHofer would that theory make sense with how the live ref-pack works? @rainersigwald I think we owe some investigation on our side first. |
I will definitely admit that "what about during the runtime build" was not something I considered when building that caching so it seems likely I created a sharp corner for you here. |
I believe I found out why the cache is a problem. In our build, we have some of the runtime/src/libraries/Microsoft.Extensions.Hosting/src/Microsoft.Extensions.Hosting.csproj Lines 7 to 8 in 426e1d9
These projects are built during the runtime/src/libraries/pretest.proj Lines 71 to 84 in 426e1d9
As a result, we cache the ref pack contents before we generate the platform manifest. We basically fall into the exact case of "ref pack changes during a build" that the caching step explicitly doesn't support: I've validated locally that disabling the cache fixes the AllConfigurations build. I'll finish up the change and push it to this branch. For now, we'll probably have to disable the cache. A better long term solution would be to finish constructing the ref pack with the platform manifest and all related data files before building any assemblies that would reference Microsoft.NETCore.App through a FrameworkReference. |
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.
FYI @dsplaisted @marcpopMSFT -- the targeting pack caching I added to SDK broke runtime but the escape hatch seems like it's keeping things ok.
@mmitche are we uploading our shipped artifacts to our dotnet-public mirror feed? The shipped runtime packs for RC2 aren't on the dotnet-public feed, which is causing our builds to fail when attempting to consume them. The |
We are, but these are new (or new-ish) packages and so they aren't auto-mirrored |
Can you ping this thread once they're uploaded? That looks to be the next blocker on this PR. |
I'm resolving this now by uploading all the shipping packages to public |
Done. |
1095c8e
to
5bba0c7
Compare
…ng the build, which the cache doesn't support.
Co-authored-by: Rainer Sigwald <raines@microsoft.com>
They shouldn't directly use that... but it's possible something leaked in... |
FYI I do not think these machines are running on ARM64 hardware actions/runner-images#2187 |
This PR fails on my x64 Mac with the following error:
|
@agocke what macOS version do you have? |
The failure is obviously unexpected, but the exit code might be expected. Can you get the XML file from the tests - that will have much more detail about the failure. |
Unfortunately, I don't see an XML file in the artifacts/TestResults/Release directory. Looks like it may have failed poorly |
@agocke can you try running |
Okay I got a repro locally. The repro requires OSX 11.6 x64 for some reason. There is one test failure and another failure that causes the test host to crash: Test failure: MultilevelSharedFxLookup.SharedMultilevelFxLookup_Must_Not_RollForward_if_Framework_Version_is_Specified_Through_Argument. The test host process crashes during this test: FrameworkResolution.MultipleHives.FrameworkHiveSelection_GlobalHiveWithBetterMatch. |
I forgot to explicitly filter out the attributed tests on my |
So I guess there's no local repro yet - right? |
I'm finishing up one now. Was waiting to post again until I have finalized results. I think I've narrowed it down to a particular portion of the test infra for the installer tests. Will share more once I've validated that I can get a clean build by disabling some of the tests. |
I've validated that I found the failures. The test crashes are all contained in the @vitek-karas @agocke to unblock this PR, can I open an issue for the failures and disable the tests on macOS against the new issue? |
Fine with me |
Updating the SDK now to see if there's anything that needs attention for dotnet/runtime to consume RC2 and the final 6.0 SDK later.