Add support for Windows x64 and arm64 builds #2230
Conversation
mjcheetham
left a comment
mjcheetham
left a comment
There was a problem hiding this comment.
Thanks for your work on getting ARM64 on Windows builds! However, these changes have an issue - we cannot build in the IDE or from the command-line anymore without specifying a particular RID on Windows.
| <GenerateAssemblyInfo>false</GenerateAssemblyInfo> | ||
| <EnableDefaultItems>false</EnableDefaultItems> | ||
| <PayloadPath>$(PlatformOutPath)Installer.Windows\bin\$(Configuration)\net472\win-x86</PayloadPath> | ||
| <PayloadPath>$(PlatformOutPath)Installer.Windows\bin\$(Configuration)\net472\$(RuntimeIdentifier)</PayloadPath> |
There was a problem hiding this comment.
The RuntimeIdentifier is not set when building without a specific RID/Architecture parameter, such as when building the solution from inside of an IDE, or with dotnet build -c WindowsDebug.
Installer.Windows net472 failed with 1 error(s) (1.4s)
D:\src\gcm\src\windows\Installer.Windows\Installer.Windows.csproj(43,5): error Layout script failed with exit code 1 and message Output: D:\src\gcm\out\windows\Installer.Windows\bin\Debug\net472;Unsupported RuntimeIdentifier:
The other 'Installer/Packacing' projects for macOS/Linux don't do much except shell out to a shell script that dynamically computes the current host's RID when it's not specified.
We can probably do some MSBuild fun with properties and discovering the current host's arch if RID has not been explicitly specified.
OR.. mimic the macOS/Linux implementations and create some layout.ps1 and pack.ps1 scripts; not relying on project-project dependencies to build the PayloadPath contents.
There was a problem hiding this comment.
Great catch, thank you! I just updated the implementation to default to the host architecture if a RuntimeIdentifier isn't explicitly provided. Tested building all three architectures and validated that the cleanup logic from layout.ps1 works properly. Also tested the arm64 installer again, still looking good, also after installation.
This comment was marked as spam.
This comment was marked as spam.
dennisameling
force-pushed
the
windows-x64-support-new
branch
from
b5c80e3 to
3bc1d94
Compare
Previously, GCM was only built for x86 on Windows. This commit adds support for building for and on Windows x64 and arm64. It builds the host architecture by default and supports explicitly specifying the target architecture. Signed-off-by: Dennis Ameling <[email protected]>
dennisameling
force-pushed
the
windows-x64-support-new
branch
from
76c378b to
c6ad8f5
Compare
3 participants
Successor of #1846
Currently, GCM is only offered as an x86 build for Windows. On arm64, this results in poor performance because the code has to be fully emulated.
Luckily,
dotnetfully supportswin-arm64nowadays. Even the .NET Framework supports it! Here's some more details.This PR follows the same logic as #1633, which added support for Linux arm64. The main
git-credential-manager.exeexecutable now becomes native, while the DLLs remainAny CPU. This allows for .NET Framework to run natively on arm64. I also addedwin-x64while at it.Confirmed to work correctly both on x64 and arm64 for GitHub operations.
x64
arm64
Also confirmed to correctly generate the installers for Windows arm64. The system-wide installer also correctly installs into the 64-bit
C:\Program Files\Git Credential Managerfolder: