Native ARM64 Support

[gus33000]

Resolved / Related Issues

• Closes .NET error #3365
• Related Why drop the ARM version? #64 Add ARM/ARM64 Builds to the Release Pipeline #1247 .NET Framework Initialization Error #2860

Details of Changes

This pull request brings full ARM64 native support to the Files application. This improves greatly the user experience for ARM64 users as well as overall performance and resource usage of the application, in environments were power optimizations matter the most. It has been verified working on an ARMv8 device running in ARM64 context under Windows 11 Build 22499 for ARM64 Processors. This pull request achieves this by:

• Converting the Files.Launcher project to the newly released .NET 6
• Fixing API calls that were broken due to ABI changes with newer .NET versions
• Migrating away from the deprecated System.Management library (more information available here: System.Management doesn't work on Windows versions without .NETFramework dotnet/runtime#45143) and instead using the supported Microsoft Management Infrastructure (MMI) library
• Apply a set of project configuration workarounds due to case sensitive MSBuild scripts for Windows Application Packaging Projects and an incompatibility with newer .NET releases
• Updating the CI pipeline files and ensuring they work on azure pipeline (The regular non release pipeline has been tested working)
• Enabling ARM64 support for all project components in the solution via configuration
• Enabling ARM64 support for Custom Open Dialog and registering it inside Files.Launcher*

*This feature does not seem to work, the option reverts by itself and it looks like the component never gets registered. I am not too sure about the status of this feature. The code to register the components looked like it was meant for X86 only and surely would not work on AMD64 or anything else, due to it attempting to register x86 first, which would not work on X64 or ARM64 packages, maybe this needs to be looked into. I doubt this is an issue caused by my PR.

Turns out it this was caused by a different issue fixed in the last commit. The CustomOpenDIalog component however does not get built by the CI. Referencing the project inside Files.Launcher.csproj makes it build however the xcopy task fails which halts the build process. I believe this issue is not caused by my PR considering the revert commit makes it like before, which is copy the file if it exist or ignore.

Validation

• Built and ran the app
• Tested the changes for accessibility (Does not apply here)
• Tested the non release CI pipeline
• Ensured ACL dialogs were working as well as MTP device detection due to MMI changes

Screenshots (optional)

[gus33000]

I have reverted 9d5d7e5 because there seem to be an issue with the pipeline setup in this repository where the C++ component does not actually get queued for build, it did on my tests, which is a bit weird. I can remove said commit once this issue is fixed however once again, in my tests, the pipeline worked on my azure devops instance, so I do not understand this issue. (Moreover, it appears the custom file dialog functionality ain't quite working anyway). The application also did build locally just fine.

[gus33000]

QuickLook detection confirmed working, as well as device detection on ARM64.
Context Menus work, icons too, ACL dialog as well.

IMG_5901.MOV

Files.UWP.ARM64.MOV

[gus33000]

Custom file open dialog was verified working by manually registering it (given the option is hidden in the app) and building a package locally (given CI does not build the component). Video below

Files.Custom.Open.Dialog.MOV

.

[yaira2]

Really nice work! Thank you ❤️

[lukeblevins]

Great work, Gus! I'll take care of moving to System.Text.Json in a future PR.

[yaira2]

@gus33000 is the full trust process working for you in release mode?

[gus33000]

@gus33000 is the full trust process working for you in release mode?

Yes it is, see all of my videos posted above.

[gave92]

@gus33000 could you take a look at the changes made to DeviceWatcher.cs?
I believe this:

Files/Files.Launcher/DeviceWatcher.cs

Line 43 in fe684bc

CimInstance obj = e.NewEvent.Instance;

should be:

CimInstance obj = e.NewEvent.Instance.CimInstanceProperties["TargetInstance"].Value

[gus33000]

@gus33000 could you take a look at the changes made to DeviceWatcher.cs? I believe this:

Files/Files.Launcher/DeviceWatcher.cs

Line 43 in fe684bc

CimInstance obj = e.NewEvent.Instance;

should be:

CimInstance obj = e.NewEvent.Instance.CimInstanceProperties["TargetInstance"].Value

Looking into it now, just woke up so that might take some time. From testing the above's code worked but I can see if your suggestion makes a difference

[gus33000]

@gave92 Had a look with a debugger, you're right looks like an issue stepped in here. I'm going to do a PR to address this. Thanks for shedding light on this!