dotnet
Windows Arm64 support
Is your feature request related to a problem? Please describe.
Currently, dotnet sign explicitly targets Windows x64. This presents a problem when needing to run the tool from Windows arm64 devices running dotnet, as the sign.dll cannot be loaded from that context.
Unhandled exception. System.IO.FileLoadException: Could not load file or assembly 'sign, Version=0.9.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
With the debut of the Windows arm64 GitHub Actions runners, this is more imperative to support - otherwise we miss out on an opportunity to fully support dotnet in its entirety, especially on ALL Windows platforms.
Describe the solution you'd like
A clear and concise description of what you want to happen.
I would like to see dotnet sign to emit architecture specific artifacts to support running from either the x64 or arm64 Windows hosts.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
An alternative solution is to run the x64 dotnet binary and run the sign.dll from where the tool is installed.
Example)
"c:\Program Files\dotnet\x64\dotnet.exe" %USERPROFILE%\.dotnet\tools\.store\sign\0.9.1-beta.25181.2\sign\0.9.1-beta.25181.2\tools\net8.0\any\sign.dll
This step is obviously tedious and removes the point of calling sign.
Additional context Include the output of sign --version. Add any other context about the problem here.
Reference to @dlemstra who originally alerted me to this https://bsky.app/profile/dirk.lemstra.org/post/3lmxetzgdcc2c
Sign needs to be platform specific due to other native dependencies. It's not recommended to run sign on the same runner as a build for security reasons, sign can be run on a Windows x64 agent for the signing step only.
Sign needs to be platform specific due to other native dependencies. It's not recommended to run sign on the same runner as a build for security reasons, sign can be run on a Windows x64 agent for the signing step only.
Do those other native dependencies have arm64 versions? I understand not running on the same runner as a build for those security reasons, but we should work towards that other agent being an arm64 agent even for the signing step. If those native dependencies can be built to target arm64, then we should have a full native assets generated.
Sign needs to be platform specific due to other native dependencies. It's not recommended to run sign on the same runner as a build for security reasons, sign can be run on a Windows x64 agent for the signing step only.
Do those other native dependencies have arm64 versions? I understand not running on the same runner as a build for those security reasons, but we should work towards that other agent being an arm64 agent even for the signing step. If those native dependencies can be built to target arm64, then we should have a full native assets generated.
Not necessarily because of the SIPs (the Authenticode plugins).
Sign needs to be platform specific due to other native dependencies. It's not recommended to run sign on the same runner as a build for security reasons, sign can be run on a Windows x64 agent for the signing step only.
Do those other native dependencies have arm64 versions? I understand not running on the same runner as a build for those security reasons, but we should work towards that other agent being an arm64 agent even for the signing step. If those native dependencies can be built to target arm64, then we should have a full native assets generated.
Not necessarily because of the SIPs (the Authenticode plugins).
The same https://www.nuget.org/packages/Microsoft.Windows.SDK.BuildTools 26100.1742 has an arm64 version of all these assets.
Those aren't the only ones. Microsoft.Dynamics.BusinessCentral.Sip.Main, for example, does not.
Gotcha. That's fair. This is tricky because the dotnet tool install will generate a stub executable geared towards the architecture of the dotnet SDK it's executed from, so even though the dll itself is x64 compiled, when dotnet tool install sign -g --prerelease is executed - it will generate an arm64 sign.exe stub on an arm64 device.
Arm64EC to the rescue! At least for dotnet tool that is. Could be a good solution in fact, as it could load both arm64 and x64 DLLs. I guess it shouldn't be too much work to hack a simple arm64ec host together 🤔
Arm64EC to the rescue! At least for
dotnet toolthat is. Could be a good solution in fact, as it could load both arm64 and x64 DLLs. I guess it shouldn't be too much work to hack a simple arm64ec host together 🤔
Well, more than a host.... You'd need an arm64ec Runtime. I've asked the dotnet team and those who work on the runtime specifically about this. It's not as easy to pull off as I thought it would be.
As for ARM64EC, Sign CLI does use native interop, and according to this, native interop isn't supported in ARM64EC.
It should be possible to offer an Arm64 build of sign that works with the set of plugins that can be compiled to Arm64. Why not?
