Add Arm64 to list of architectures in Module Initialization. #4251
Conversation
Add arm64 path and logic for dependencies into module.
Add Arm64 to list of ValidArchs
microsoft-github-policy-service
bot
added
the
Issue-Bug
|
Currently the arm64 modules are not published. We'll need to validate the arm64 modules and make an internal pipeline change to publish them. Then we can take in this change. Thanks. |
That answered the question I meant to ask earlier because I noticed it's only building Thanks for the clarification! |
|
@snickler thanks for the PR! We've been going through a lot of churn with our build pipelines and new internal requirements. Thanks so much for calling this out and doing something about it. |
|
@snickler where you able to run the module locally? |
I'm able to run the module locally to some extent. I'm trying to figure out what it's complaining about, but I believe it MAY have to do with the Any CPU projects. I'm now getting a |
OH WAIT @msftrubengu, I DID get it working. I made the mistake of testing with a Microsoft Store installed version of PowerShell.
I did find something I need to debug with it actually installing a package, because it blows up PowerShell:
|
|
Regarding AnyCPU thing, I think ARM64 has to be specified separately, according to https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-target-framework-and-target-platform?view=vs-2022#target-platform. |
|
@snickler I was able to repro that AV using the non packaged version of PowerShell 7 for arm64. Yes, the package got installed and PowerShell crashed. Regardless, there's a known issue with running the module in the packaged version of PowerShell for all architectures that we want to address before calling it good for ARM64. Specially because winget's default installation of PowerShell in arm64 is the msix. |
This PR enables arm64 for the Microsoft.WinGet.Client module. There's an OS bug that causes an AV (see #4251 (comment)) in arm64 devices that was fixed in a newer Windows build. The AV message is just shown for PowerShell Core. In Windows PowerShell no error message is displayed but it won't display progress either. Regardless, the winget install/uninstall operation still happens as the progress is shown after we asked winget to install the app. The configuration module doesn't get affected by the OS bug, so there's no need to disable progress. To keep showing progress the module now looks at the OS version. If the processor architecture is arm64 and the OS version is lower than 10.0.26068.0 progress is disabled in the module. I verified manually on arm64 builds with and without the fix. Fixes #4169 ###### Microsoft Reviewers: [Open in CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/microsoft/winget-cli/pull/4392)
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This PR enables arm64 for the Microsoft.WinGet.Client module. There's an OS bug that causes an AV (see microsoft#4251 (comment)) in arm64 devices that was fixed in a newer Windows build. The AV message is just shown for PowerShell Core. In Windows PowerShell no error message is displayed but it won't display progress either. Regardless, the winget install/uninstall operation still happens as the progress is shown after we asked winget to install the app. The configuration module doesn't get affected by the OS bug, so there's no need to disable progress. To keep showing progress the module now looks at the OS version. If the processor architecture is arm64 and the OS version is lower than 10.0.26068.0 progress is disabled in the module. I verified manually on arm64 builds with and without the fix. Fixes microsoft#4169 ###### Microsoft Reviewers: [Open in CodeFlow](https://microsoft.github.io/open-pr/?codeflow=https://github.com/microsoft/winget-cli/pull/4392)
This PR addresses an issue that prevents the WinGet Cmdlets from loading in an Arm64 PowerShell 7.x environment.
Microsoft Reviewers: Open in CodeFlow