ARM64 backport to .NET 5: Cherry-pick Arm64 bundle fix from NET 6 #1629
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Alexandre Zollinger Chohfi <[email protected]> Co-authored-by: Marcpems <[email protected]> Co-authored-by: Juan Sebastian Hoyos Ayala <[email protected]> Co-authored-by: Ryland <[email protected]>
This was referenced May 20, 2021
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Backport NET6 WPF ARM64 and enable WinForms ARM64 support on NET5.
Add NET5 WPF ARM64 support.
Unblock WinForms on NET5 ARM64, working but disabled on NET5 due to lack of WPF ARM64 support.
Public PRs
WPF public (these PRs need to go in separately due to WPF internal relying on the WPF Arcade SDK package):
dotnet/wpf#4522
dotnet/wpf#4523
WindowsDesktop:
#1629
SDK:
No changes are required in main.
Installer:
WindowsDesktop NET5 ARM64: Include WindowsDesktop ARM64 in the Installer by ryalanms · Pull Request #10699 · dotnet/installer (github.com)
Customer Impact
These changes allow existing NET5 customers to build WPF and WinForms applications for ARM64
Regression?
No. This is a new feature.
WinForms was available in NET5 preview, then disabled, due to lack of WPF ARM64 support. This unblocks WinForms.
Risk
Low.
There are no existing ARM64 WPF or WinForms application on NET5 to break, and these changes have been in NET 6 Preview since Preview 1.
Some files that have conditionally compiled sections shared with x86/x64. There is a small risk of a regression due these modifications.
The addition of new packages and changes to the Installer pose some risk, but we have built and tested all PRs end-to-end (locally and through Azure) and tested the Installer on arm64 and x64/x86.
Is there a packaging impact?
Yes. This requires new runtime and targeting packs.
Testing
Manual and automated testing was performed on a local test Installer build, created with the E2E changes from all five repos. An E2E build on Azure using the PRs (with required feed and version updates) was also created to verify that we will not introduce build issues.
WPF has ported 49% of the netcore test automation to ARM64. There are parts of the test infrastructure (touch driver, printer driver, and others) that do not have ARM64 versions available and must be rewritten. Manual tests were run to fill in the test gaps.
For the manual tests, 202 test applications from WPF’s samples repo were built and run. The sample application behavior was compared against the same applications running on NET5 x64 and net6 ARM64. There were no differences observed between NET6 ARM64 and NET5 ARM64.
All ported test automation was run against the current NET5 x86 and NET5 x64 builds (without any changes), and results were compared against NET5 ARM64. There are five failures that are being investigated, but we do not consider these blocking.
For regression testing, a full test pass was run against x86 and x64 NET5 Installer builds containing the WPF ARM64 changes. This covered all OS versions: Windows 7 SP1, Windows Blue, Windows Server 2012 R2 SP1, Win10 RS1, RS3, RS4, Server 2019, 21H1, Server 2016, 19H1, 19H2, 20H1, 20H2. No new issues were found (introduced due to these changes) with x86 or x64.
Non-functioning bitmap effects were discovered, Blur and DropShadow, which work on non-ARM64 plaforms, but are considered non-blocking. No blocking issues were found in automation or manual testing.
Co-authored-by: Alexandre Zollinger Chohfi <...>
Co-authored-by: Marcpems <...>
Co-authored-by: Juan Sebastian Hoyos Ayala <...>
Co-authored-by: Ryland [email protected]
/cc @azchohfi @hoyosjs @marcpems