WPF ARM64 Support now available in .NET 6 Preview 1

[predavid]

WPF ARM64 support is now available in .NET 6.0 Preview 1

Build available here

Please provide your feedback

[predavid]

Folks,
We'd love to continue to hear your feedback on trying out the WPF ARM64 Support in .NET6 Preview 1. Could you share your experience with us and help us fine tune and fix bugs that you encounter?

[christopher-rtf]

Hi @predavid some quick feedback for you.

I'm trying to get up and running with WPF on Windows 10 ARM64, and am happy to provide feedback.

I have had no success debugging a WPF application on ARM64 with .NET 6 Preview 1, either locally on an ARM64 device or using Remote Debug. I am able to "dotnet build" and "dotnet run" the WPF app using pure ARM64, but cannot debug it.

My setup
Development PC: Windows 10 x64, VS2019 Preview 4, .NET 6 SDK Preview 1 x64
ARM64 PC: Surface Pro X, Windows 10 ARM64, Remote Tools for VS2019 (ARM64), .NET 6 SDK Preview 1 ARM64
Test App: Plain WPF app, with a button added that has a click handler (so I can put a breakpoint in the handler)

I did not install the x86 remote debug tools or the x86 version of the .NET 6 SDK Preview on the Surface Pro X.

Question
Do you have any instructions on how to debug WPF applications on ARM64 (either locally or remotely, using either Visual Studio 2019 Preview 4 or using Visual Studio Code)?

For reference, here are all the things I attempted. I gave it the old college try. I am having zero success.

Attempt 1
Compiled sample app for "Any CPU" on my x64 dev machine, copied the bin folder to my Surface Pro X (same folder path on both devices). I then ran Remote Debugger on the Surface Pro X and selected the auto-detected Surface Pro X in the csproj's debug-tab properties in VS.

This was not successful. I think that Remote Debugger is trying to launch the EXE (which is an Intel app) instead of the platform-agnostic DLL. [Knowing this, I did a "dotnet build" on the Surface Pro X so that an ARM64 EXE was written out instead; VS2019 Preview 4 was then able to remotely launch and stop the app...but could not debug it, saying that no debug symbols were found/loaded.]

Attempt 2
I tried copying the ARM64-compiled files from the ARM64 device to the x64 development computer. That did not help...same "no debug symbols" error, no ability to debug.

Attempt 3
I changed the csproj settings to launch the EXE directly on the target machine (instead of launching "project"). And I separately also configured the csproj debug settings to launch "dotnet run" and also "dotnet [appname].dll". All of those resulted in launching the application...but still without any ability to debug it ("no debug symbols").

Attempt 4
I added an "x64" target to the solution and then manually edited the solution and project files to change the text "x64" to "ARM64", hoping that Visual Studio would build ARM64 files instead. [VS2019 won't let me add ARM64 for a WPF application directly.]. This did not result in an ARM64 executable being built, and this attempt also failed.

Thinking that perhaps Visual Studio built the files as Intel because there was no ARM64 SDK installed, I then also tried installing the .NET 6 Preview 1 SDK for ARM64 on my x64 machine. That of course did not work, as the installer targets only ARM64 CPUs.

Attempt 5
Finally I tried installing VS2019 Preview 4 on the Surface Pro X itself (which the VS2019 Preview 4 installer warns is a terrible idea, noting that Remote Debugger is a much better option). I can build the app as ARM64 and can run it from the command line, but I cannot debug it. When I press F5 in the VS2019 Preview 4 IDE, it says that "the debugger is not properly installed" and instructs me to repair my VS2019 Preview 4 installation.

[christopher-rtf]

In case this is helpful to others, I found two successful ways to debug WPF on ARM64. Plus one that wouldn't work because Remote Deploy doesn't want to remote debug via loopback.

Attempt 6 (Success)
I installed the latest Insider build of Windows 10 Pro on my Surface Pro X so that I could use Hyper-V. I downloaded a VHDX of Windows 10 for ARM64 from Microsoft's website, and then installed the VS2019 Remote Debugger inside of it.

By sharing a folder inside my Hyper-V instance (or installing the optional Windows component "OpenSSH Server"), I'm able to compile WPF and other apps for "Any CPU" architecture inside VS2019 Preview 4 on my Surface Pro X. Then I can copy the folder over to the VM running in Hyper-V, start Remote Debugger in the Hyper-V VM and remote deploy and debug from VS2019. All of this is happening on my Surface Pro X.

I also noted that I can add "x86" and "x64" variants to my WPF project in VS2019 Preview 4, save out a solution file, and then manually edit both the solution file and the project to add an "ARM64" option (copy and pasting the x64 entries and just renaming them to ARM64). VS2019 itself won't allow this, but it compiles the three variants without incident after VS reloads the edited files.

If you have two ARM64 machines, it should be easy to edit in VS2019 on one and debug the process running on the other (without needing Hyper-V). At least for me, the Hyper-V solution was extremely extremely slow on a maxed-out Surface Pro X (possibly due to the beta nature of the Windows Insider builds).

Attempt 7 (Biggest Success)
By using "attach to remote process" from VS2019 Preview 4 instead of trying to start the app via VS2019 Preview 4, I was able to remote debug an app on my Surface Pro X. I had to "dotnet build" from the command-line on that machine first and then copy the files back to my x64 machine...but then I could interactively remote-debug from VS2019, no problems.

Note that this has the caveat of needing to put a long pause (or perhaps a messagebox or readline) in the application's startup code temporarily...if one needs to debug code that runs early in the application's startup.

Attempt 8 (Another failure, just for documentation)
After my success debugging from an ARM64 machine to another one (through Hyper-V), I tried to debug the C# application locally using Remote Debugger as a middleman-conduit. Unfortunately VS2019 Preview 4 seems too smart for my tactics, because every time I tried connecting (via 'localhost', '127.0.0.1', the computer name or any other IP registered to my local machine), VS2019 simply tried to run and debug locally and ignored my 'remote' selection. There may be some trick which could make this work...but it eluded me.

Summary
It is possible to debug WPF apps on ARM today, either by compiling the apps on the ARM machine and then debugging from an x86/x64 machine...or by compiling on an ARM64 machine and then deploying and debugging to another ARM64 machine (or ARM64 VM).

With some luck, Visual Studio will gain support for cross-compiling WoA64 apps on x64 machines or Visual Studio will be compiled for ARM64 and support local ARM64 debugging.

It's really cool seeing WPF on ARM64! If I run into any problems porting our application over, I'll post here with my experiences.

[predavid]

@christopher-rtf - Thanks for insights into success w.r.t 7 and 8.
@ryalanms - can you elaborate on other debugging mechanisms for a WPF application on ARM64 with .NET 6 Preview 1?

[Samuel12321]

@predavid
I'm one of the developers for ModernFlyouts, it seems WPF ARM64 Support in .NET 6 Doesn't work for desktop bridge applications that support multiple languages, it seems the “/platform” option of ALINK (al.exe) does not support arm64.
Publish fails with ' "ARM64" is not a valid setting for option platform' file ALINK

[Samuel12321]

@predavid
I'm one of the developers for ModernFlyouts, it seems WPF ARM64 Support in .NET 6 Doesn't work for desktop bridge applications that support multiple languages, it seems the “/platform” option of ALINK (al.exe) does not support arm64.
Publish fails with ' "ARM64" is not a valid setting for option platform' file ALINK

Turns out visual studio's ALINK (al.exe) doesn't support building for arm64. A workaround is available.
https://developercommunity.visualstudio.com/t/alink-alexe-does-not-support-arm64-windows/1325460