fix(windows): make Windows ARM64 build start and package correctly - #1809
fix(windows): make Windows ARM64 build start and package correctly#1809aequivalent2 wants to merge 1 commit into
Conversation
ShGKme
left a comment
There was a problem hiding this comment.
Thank you and sorry we missed the arm64. One day we'll have a Windows arm64 device for testing =D
Instead of ignoring arm64, let's actually add support for it.
I'm preparing a new release of the package with arm64 support.
You can test it locally with:
npm i github:nextcloud-deps/vscode-windows-registry#fix/build-arm64If you have any errors on install, just ignore scripts:
npm i --ignore-scripts github:nextcloud-deps/vscode-windows-registry#fix/build-arm64 |
Asking just in case. If this PR is AI Assisted, please, add Details: https://github.com/nextcloud/server/blob/master/.github/CONTRIBUTING.md#ai-assisted-contributions |
3a4b876 to
927bb6a
Compare
|
Ive added a few things |
|
Is there anything what has to be done now? |
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
|
Sorry is @ShGKme is there a problem with my pull request? |
|
@aequivalent2 To have a complete arm64 support here, we needed a new release of the It was only done at the end of the last week in: Now you can rebase your PR onto |
ShGKme
left a comment
There was a problem hiding this comment.
Could you adjust some comments to not have a misleading description for the electron-wix-msi and to not have too many extra comments? Comments describing the code are an additional part of the code that needs to be maintained (be consistent with the code changes in the future).
All the rest is good, but a rebase onto main is needed to test with the actual @vscode/windows-registry version, supporting arm64.
4e88f8c to
32e5f19
Compare
|
Hello, the new electron wixx 8.0.0 Beta added an Arch Check which prevents arm64, thats why i removed this change. |
I may propose to add the As far as I understand, having an x64 installer should have no negative effect on the installed arm64 application. The app itself is Could you confirm, there are no issues with the x64 installer for the arm64 app on Windows ARM on your side? |
|
With this check it is no longer possible to package the msi, you can see the error in the workflow run below https://github.com/aequivalent2/nextcloud-desktop-arm64/actions/runs/30529848769/job/90829330314 |
|
I understand passing But it is unclear from the action if it's running with
Are you sure, this is a run with |
|
Could you also remove the 2 last commits? |
|
Hello, this run worked with the previous version without the check, now there is a failure https://github.com/aequivalent2/nextcloud-desktop-arm64/actions/runs/30432968591/job/90514166207 package:arm64:msi was possible before but is not possible anymore i guess |
32e5f19 to
5597648
Compare
…of hardcoded x64 getWindowsRegistryItem() threw unconditionally on any non-x64 architecture before ever attempting to load the native @vscode/windows-registry module, crashing the app on startup on arm64. Resolve the native module path per process.arch instead of a hardcoded win32-x64 path, and treat a missing prebuild for the current architecture as a recoverable error (return undefined) instead of throwing. Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Leonhard Ruckert <leonhard.ruckert@outlook.com>
5597648 to
2d61313
Compare

Summary
One fixes needed for a working win32-arm64 build/release, on top of the packaging groundwork
from #1725:
getWindowsRegistryItem()(
src/app/windows.utils.ts) threw unconditionally on any non-x64 architecture, before everattempting to load the native
@vscode/windows-registrymodule. SincereadManagedConfig()(src/app/managedConfig.service.ts) is called at module scope inAppConfig.ts, i.e. on every app start, this throw is never caught: Error: getWindowsRegistryItem is only available on x64Changes
process.archinstead of a hardcodedwin32-x64path; treat a missing prebuild for the current architecture as a recoverableerror (return
undefined) instead of throwing.Testing
main(git am, no conflicts).windows.utils.tschange with esbuild (syntax/bundle check).Related