Build & run GitExtensions in Windows on Arm64

[chirontt]

I'd like to start a discussion thread about building and running GE natively in a Windows-on-Arm64 machine. The compiler & SDK tools like Visual Studio 2022 and .NET 6 are already available for native Arm64 development, so hopefully it's just a matter of compiling GE to Arm64 executable so that it'll run natively in Windows 11 on the Arm64 box. But I'm a newbie in these .NET things, so bear with me if the following may not be quite accurate.

Note that Windows 11 on Arm64 has a x64 translation layer such that it supports running successfully most of existing x64 binaries/executables unchanged on the Arm64 box. The existing x86 GE release can run, for example, with caveats like #9755 (comment). But the translation layer incurs a performance penalty, i.e. slower, as compared to running native Arm64 software. Given that my Arm64 box isn't as fast as an equivalent x64 machine, it would be best to squeeze out more performance if GE could be built and run natively as Arm64 executable. Another slowdown is Git for Windows itself, which is not yet available natively in Arm64, so it requires the x64 translation layer every time it is invoked. (And GE uses Git for Windows extensively.)

I'll detail the steps I was doing to facilitate discussions & feedback.

1. Following the build instructions here, to clone and build GE with the dotnet build command, the build completes successfully and produces the portable GE in the folder artifacts\Debug\bin\GitExtensions\net6.0-windows. I guess the GE project doesn't specify any platform, hence it defaults to AnyCPU and so the build would work with ARM64 platform too. Examining the resulting GitExtensions.exe with the dumpbin utility shows that it's an Arm64 executable:

> dumpbin /headers GitExtensions.exe | findstr "machine"
            AA64 machine (ARM64)

2. Then when starting up GE with the dotnet run --project GitExtensions command, or by double-clicking the above GitExtensions.exe file, it takes a long time (around half a minute) to show the GE dashboard. Why is that? What is GE doing taking so long before showing the dashboard?

Then opening the Settings dialog, with Tools --> Settings, I have the same 'frozen' problem as described in #10215. The CPU usage of GE is about 20% when in this state, and the GE process need be killed via the Task Manager. This problem is 100% reproducible with the Arm64 executable. And it occurs whenever I'm in the dashboard, like when first starting up, or when closing a repository to go back to the dashboard.

Also, as mentioned in #9755 (comment), ConEmu need be disabled for all Git commands to work on Arm64. Actually disabling ConEmu makes all Git commands seem fast to me, so it's good UX to me. (With GE, the ConEmu64.exe process gets stuck and need be killed with Task Manager. But when launched as a stand-alone program, ConEmu64.exe actually works, with some error about 'injecting hooks FAILED', but the console window works.)

3. Executing the tests, with the dotnet test command, mostly fail, with error about testhost.dll:

Testhost process for source(s) 'C:\dev\dotnet\gitextensions\artifacts\Debug\bin\tests\UnitTests\GitUI.Tests\net6.0-windows\GitUI.Tests.dll' exited with error: Unhandled exception. System.BadImageFormatException: Could not load file or assembly 'C:\dev\dotnet\gitextensions\artifacts\Debug\bin\tests\UnitTests\GitUI.Tests\net6.0-windows\testhost.dll'. An attempt was made to load a program with an incorrect format.
File name: 'C:\dev\dotnet\gitextensions\artifacts\Debug\bin\tests\UnitTests\GitUI.Tests\net6.0-windows\testhost.dll'
. Please check the diagnostic logs for more information.

I guess testhost.dll is an x86 library, so it fails to load in an Arm64 GE process. Where does this testhost.dll come from?

More to come...

[RussKie]

We do specify bitness here:

gitextensions/GitExtensions/GitExtensions.csproj

Line 13 in 6f0cb7f

<Prefer32bit>true</Prefer32bit>

I vaguely remember a discussion about dropping this setting and building "any cpu", but my tests resulted in crashes.

[chirontt]

I've tried commented out that Line 13 and rebuilt GE, but it makes no difference in test failures in testhost.dll loading.

Out of curiosity, I ran dumpbin on the GitExtensions.dll file, and it gives:

> dumpbin /headers GitExtensions.dll | findstr "machine"
             14C machine (x86)

What a surprise! GitExtensions.exe is Arm64 executable, but the GitExtensions.dll is x86 DLL. How can they work together at runtime?

[RussKie]

Related: #9990

[RussKie]

diff --git a/GitExtensions/GitExtensions.csproj b/GitExtensions/GitExtensions.csproj
index ea34b12a5..35f93192a 100644
--- a/GitExtensions/GitExtensions.csproj
+++ b/GitExtensions/GitExtensions.csproj
@@ -10,7 +10,7 @@
     <ApplicationIcon>..\Logo\git-extensions-logo.ico</ApplicationIcon>
     <StartupObject />
 
-    <Prefer32bit>true</Prefer32bit>
+    <Prefer32bit>false</Prefer32bit>

dotnet build -c Release
.\artifacts\Release\bin\GitExtensions\net6.0-windows\GitExtensions.exe

[RussKie]

That was run on my home amd64 workstation, I'll see if I can find time to build that on an arm64 workstation at work.

[chirontt]

Continuing...

4. To package the GE app, the dotnet build .\scripts\native.proj need be run. But after looking through the scripts\native.proj file, I realize that the file is for building native C++ projects GitExtSshAskPass & GitExtensionsShellEx for x86/x64 platforms, which wouldn't work with my Arm64 tools. So I create a new similar file scripts\native_arm64.proj, to build those C++ projects for Arm64 platform. Of course, those projects' .vcxproj files need be modified to add the ARM64 platform to them, in addition to their existing Win32 & x64 platforms. Then running the command:

dotnet build .\scripts\native_arm64.proj

would work and produce the GitExtSshAskPass.exe & GitExtensionsShellEx64.dll files respectively. And producing the GitExtensionsShellEx32.dll, which is mandatory to GE, is just a manual copy of the GitExtensionsShellEx64.dll file. With these binary files present in the portable GE area, the Shell extensions can be registered and working in WoA.

[RussKie]

I don't believe you need a dedicate project for arm64, the existing one should be augmented to include the arm support.

[RussKie]

Also, the native dependencies aren't required for the main app to work, they must be built for the redistributable bundles.

[chirontt]

Continuing...

5. Running the dotnet publish command would eventually fail to produce .msi file for GE distribution:

...
  Zipping directory "C:\dev\dotnet\gitextensions\artifacts\Debug\publish\GitExtensions\" to "C:\dev\dotnet\gitextension
  s\artifacts\Debug\publish\GitExtensions-Portable-33.33.33.0-6f0cb7f1b.zip".
  MSBuild version 17.4.0-preview-22512-01+0a4ea3c41 for .NET Framework
  C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\msbuild.exe /bl:C:\dev\dotnet\gitextensions
  \artifacts\Debug\log\\setup.binlog /p:Configuration=Debug;Platform=x86;WiXVersion=3.11.2;Version=33.33.33.0;Artifacts
  BinPath=C:\dev\dotnet\gitextensions\artifacts\Debug\bin\;ArtifactsPublishPath=C:\dev\dotnet\gitextensions\artifacts\D
  ebug\publish\GitExtensions\;OutputPath=C:\dev\dotnet\gitextensions\artifacts\Debug\publish;TargetName=GitExtensions-3
  3.33.33.0-6f0cb7f1b /t:Build /v:q C:\dev\dotnet\gitextensions\GitExtensions\\..\Setup\Setup.wixproj
C:\Users\chiro\.nuget\packages\WiX\3.11.2\tools\wix2010.targets(735,5): error MSB4062: The "ResolveWixReferences" task
could not be loaded from the assembly C:\Users\chiro\.nuget\packages\WiX\3.11.2\build\..\tools\WixTasks.dll. Could not
load file or assembly 'Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
 one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correc
t, that the assembly and all its dependencies are available, and that the task contains a public class that implements
Microsoft.Build.Framework.ITask. [C:\dev\dotnet\gitextensions\Setup\Setup.wixproj] [C:\dev\dotnet\gitextensions\GitExte
nsions\GitExtensions.csproj]
C:\dev\dotnet\gitextensions\GitExtensions\Project.Publish.targets(306,5): error MSB3073: The command "..." exited with
code 1. [C:\dev\dotnet\gitextensions\GitExtensions\GitExtensions.csproj]

I guess, like the above test problems with loading the testhost.dll file, the WiX library's WixTasks.dll file (which is x86 binary) can't be loaded into the native Arm64 build process, hence the production of the .msi file fails. But the portable GE zip file is successfully created.

End of report.

[RussKie]

You'd need to seek help for WiX toolset here: https://github.com/wixtoolset/issues.

[chirontt]

Regarding:

Another slowdown is Git for Windows itself, which is not yet available natively in Arm64, so it requires the x64 translation layer every time it is invoked. (And GE uses Git for Windows extensively.)

Update: there is a beta version of Git for Windows port to Arm64; the port is currently being merged back to mainline.

[chirontt]

Regarding:

Then opening the Settings dialog, with Tools --> Settings, I have the same 'frozen' problem as described in #10215. The CPU usage of GE is about 20% when in this state, and the GE process need be killed via the Task Manager. This problem is 100% reproducible with the Arm64 executable. And it occurs whenever I'm in the dashboard, like when first starting up, or when closing a repository to go back to the dashboard.

Update: this problem occurs (at least in my Arm64 platform build) when running GE during development, i.e. running it via:

• the dotnet run --project GitExtensions command, or
• double-clicking the GitExtensions.exe in the artifacts\Debug\bin\GitExtensions\net6.0-windows folder.

This problem doesn't occur if using the portable GE zip distribution, from artifacts\Debug\publish folder, produced by the dotnet publish command.

[brandonh-msft]

Any update on where we're at with this? w/ the latest gitExtensions i'm still not able to run on arm64:

despite having the runtime it wants installed:

> dotnet --list-runtimes
Microsoft.AspNetCore.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.0-rc.2.23480.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.0-rc.2.23479.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.14 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.0-rc.2.23479.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[brandonh-msft]

just filed #11446

[chirontt]

@brandonh-msft I have done some manual builds of GE for Windows on Arm64, and they are available in my fork as unofficial releases. I've also documented the build steps for WoA in each release.