Revert versions to f3ac1266 level, where MicrosoftNETCoreApppackageVersion=5.0.0-alpha1.19514.1

[vatsan-madhavan]

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.App version 5.0.0-alpha1.19514.1 - this can be seen in the LHS of eng/Version.Detail.xml in https://github.com/dotnet/wpf/pull/2118/files. This version comes from WinForms through a CoherentParentDependency like this:

    <Dependency Name="Microsoft.NETCore.App" Version="5.0.0-alpha1.19514.1" CoherentParentDependency="Microsoft.Private.Winforms">

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

[AdamYoblick]

@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?

[vatsan-madhavan]

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.

[AdamYoblick]

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?

[vatsan-madhavan]

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.

[vatsan-madhavan]

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?

[AdamYoblick]

If this is blocking wpf and windowsdesktop insertions, we should just skip the failing tests imo. But I'll defer to @RussKie on this.

[RussKie]

I'll have a look.
@AdamYoblick can you please pause the core-sdk updates for the time being?

[AdamYoblick]

Done.

For reference, here's what I did:

1. darc get-subscriptions --target-repo https://github.com/dotnet/winforms --target-branch master

https://github.com/dotnet/arcade (.NET Eng - Latest) ==> 'https://github.com/dotnet/winforms' ('master')
  - Id: 4d0c844d-0758-4fc5-c1ad-08d6354da8a8
https://github.com/dotnet/runtime (.NET Core 5 Dev) ==> 'https://github.com/dotnet/winforms' ('master')
  - Id: be4b0f38-c1d5-43ab-c5d9-08d76fa9c820

The second one is the one we're interested in

2. darc subscription-status --id be4b0f38-c1d5-43ab-c5d9-08d76fa9c820 --disable
3. darc get-subscriptions --target-repo https://github.com/dotnet/winforms --target-branch master again to verify

https://github.com/dotnet/runtime (.NET Core 5 Dev) ==> 'https://github.com/dotnet/winforms' ('master')
  - Id: be4b0f38-c1d5-43ab-c5d9-08d76fa9c820
  - Update Frequency: EveryDay
  - Enabled: False

And we're good 😄

[RussKie]

The internal build succeeded

[vatsan-madhavan]

The pr into wpf is failing for a different reason now. I’ll look.

[vatsan-madhavan]

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.

[vatsan-madhavan]

update: dotnet/wpf#2306 is merged.