GE is currently built as 32-bit (except shell extensions). There has been some discussions about building a 64-bit app, not sure of the status. See also #9990
Not sure why you see GE as x64.

@silmaril42 why is this a problem?

@gerhardol I did drop Prefer32Bit=true in #11240, so the app is now run as a 64bit process. We should stop building and distributing the 32bit shell extension too, but I've completely overlooked/forgotten about it.
This is a "quality of life" kind of thing, so not a high priority for me. 

@gerhardol Here GE won't start unless .Net Core Desktop is installed in the 64 bit version. The 32 bit version didn't work for me. So this looks very much like a 64 bit application to me.

@RussKie My problem was to find the correct dependency to make a baramundi install package for GE to use in our company. Usually we can trust the installation path to point to the correct bitness. The wrong path meant we needed one extra attempt (so not very much time was wasted here).

The 4.2.1 release page already points to the correct x64 .Net installer.

I agree that this is not high priority - it's simply something that doesn't feel right at the moment, but it does work.

@gerhardol Here GE won't start unless .Net Core Desktop is installed in the 64 bit version. The 32 bit version didn't work for me. So this looks very much like a 64 bit application to me.

Correct.
The .NET apphost will check for the required .NET Desktop runtime and will point the user to the download page, if it's missing. Obviously, this poses certain difficulties (to put it mildly) in the enterprise environment, but this is (almost) the best we can do with the resources we have.

We welcome contributions though :)

A tested PR with the adapted installation path is welcome.

We should stop building and distributing the 32bit shell extension too.

GE does not use the shell extension itself. It is provided for all kind of filesystem shells - including file dialogs.
That's why we should keep the 32bit variant until most of the Windows applications have switched to x64.
When removing, we also need to adapt the registration code of the settings page.

32bit OS are getting rarer with every passing year, so it's not something we should continue to invest our efforts either.

32bit OS are getting rarer with every passing year, so it's not something we should continue to invest our efforts either.

Of course, but that's not the point. The question is "When will the support for Win32 applications be removed from Windows?"
The more important point is that there is more to be considered than removing it from the build scripts and from the installer. So rather do not touch the 32bit shell extension as long as it works without much adaptation.

The MSI installer GitExtensions-4.2.1.17611-b0c0b2848.msi installs the 64 bit application into C:\Program Files (x86)\GitExtensions if the default is left unchanged.

64 bit applications should be installed to C:\Program Files, or whatever the environment variable %ProgramFiles% points to in a 64 bit environment (this only works if the installer actually runs in a 64 bit context).

I concur with this description. Recently I've managed to generate the .msi installation file for the Windows on Arm64 version, and to my surprise, the installer defaults to C:\Program Files (x86)\GitExtensions path, which feels weird.

I agree with the OP that the installer should default to %ProgramFiles% if possible, which will suit best for both x64 and Arm64 platforms.

Where in the code base should I change this default setting?

Where in the code base should I change this default setting?

That's a $64,000 question :)

I would think the following need to happen:

1. we'd need to stop building the 32bit native projects, see ./scripts/native.proj x86 (adding for completeness, not strictly related to the installer)
2. remove references to the 32bit native artifacts in the installer under ./Setup folder.
   • E.g., there are references in Product.wxs
   • E.g., does RegisterShellExtension.wxi register the both 32bit and 64bit shell extensions?
3. update the installer to use %ProgramFiles%
4. test it all works

It is also worth noting that the current version of Wix is pretty old, and it should be updated to the new version (v4 or v5), however, it is time consuming, and likely require dealing with some breaking changes that the new version introduced.
However, since there's no one in the Core team with a knowledge of the installer, this work is sitting in the "too hard basket".

The culprit is here (hard-coded Platform=x86 value):

I'm preparing a PR to fix it, and we would discuss it further about my proposal there.

I don't think we should worry too much about making GE going strictly 32-bit or strictly 64-bit. The existing GE build can be installed in either places and Windows won't complain. I think Windows accepts partially-64-bit apps in Program Files (x86), like the GE app, and partially-32-bit apps in Program Files folder; they are just installation folders, basically, with no runtime check.

Here's a twist.
Since v4.0, the MSI installer still claims to install GE on 32 bit Windows, but it erroneously installs the 64 bit binary, which cannot run in that environment. That's a bug, whichever way you look at it.
The latest version (v4.2.1) installer still does the same thing.
Given that GE is still supposed to be x86 compatible, and all it's dependencies still support x86, and the MSI installer runs without any complaint on x86 Windows, this behaviour is a little embarrassing.

We don't (actively) support x86 since Microsoft stopped supporting it. If you still use x86 platform you can build installers for it yourself.