Revert versions to f3ac1266 level, where MicrosoftNETCoreApppackageVersion=5.0.0-alpha1.19514.1 #2497
Conversation
…rsion=5.0.0-alpha1.19514.1. This version is very likely compatible with the WPF repo right now.
|
@vatsan-madhavan The only thing I'm worried about here is - all these dependency versions are revved by our darc subscriptions. Is this going to prevent us from taking arcade fixes (via maestro) if we need them? |
|
Arcade updates are in the tools-channel. That should be fine. I'm reverting the whole file to match the f3ac126 - since I didn't want to manually pick and choose what to revert and what to keep. Once this flows correctly, tools-channel updates can continue flowing, but dev-channel updates have to be stopped until we get compiler fixes figured out. |
|
Ah ok, then we just have to make sure not to take any other package updates through maestro until this is resolved. @RussKie I guess we just let them sit? |
yes. until we fix the compiler (and possibly coreclr alongwith it), (a) either winforms+wpf stops corefx+coreclr ingestion; or (b) winforms+wpf stops insertion into core-sdk. (b) is the current state - i'm proposing that we switch to (a). switching to (a) requires that we "rewind" a bit first - that's what this PR does. |
|
i'm not sure how to fixup the failing tests - i think they depend on new API's from corefx that don't exist in the older version... one of you have any ideas? |
|
If this is blocking wpf and windowsdesktop insertions, we should just skip the failing tests imo. But I'll defer to @RussKie on this. |
|
I'll have a look. |
|
Done. For reference, here's what I did:
The second one is the one we're interested in
And we're good 😄 |
Comment out failing test.
|
The internal build succeeded |
|
The pr into wpf is failing for a different reason now. I’ll look. |
|
I closed out the old PR from winforms and triggered a new one - dotnet/wpf#2306. It conforms to my theory - it's only attempting to update winforms transport package version and little else. |
|
update: dotnet/wpf#2306 is merged. |
Revert versions to f3ac126 level, where MicrosoftNETCoreApppackageVersion=5.0.0-alpha1.19514.1 until dotnet/wpf#2399 (comment) is resolved. This version is very likely compatible with the WPF repo right now.
ghost
locked as resolved and limited conversation to collaborators
Temporarily, revert versions to f3ac1266 level, where
MicrosoftNETCoreApppackageVersion=5.0.0-alpha1.19514.1.This version is very likely compatible with the WPF repo right now.
--
In dotnet/wpf#2118, transport packages originating from WinForms are unable to build successfully due to a CoreCLR + Compiler problem. This prevents WinForms work from flowing into dotnet/windowsdesktop and ultimately into dotnet/core-sdk.
WPF currently ingests
Microsoft.NETCore.Appversion5.0.0-alpha1.19514.1- this can be seen in the LHS ofeng/Version.Detail.xmlin https://github.com/dotnet/wpf/pull/2118/files. This version comes from WinForms through aCoherentParentDependencylike this:If WinForms repo were moved back temporarily to this version of
Microsoft.NETCore.App, then the packages it would subsequently flow into WPF ought to build cleanly, and then flow all the way to dotnet/windowsdesktop and later onto dotnet/core-sdk.Once WPF gets fixes for C++ compiler and corresponding updates for CoreCLR (which could take a while), WinForms can fast-forward to building against latest versions of CoreFx/CoreCLR.
/cc @RussKie, @AdamYoblick, @merriemcgaw
/cc @rladuca
Microsoft Reviewers: Open in CodeFlow