Repository navigation
feat(win32): default -Architecture to the device's 64-bit host - #30
Conversation
Invoke-IntuneDetectionTest, Invoke-IntuneRequirementTest and Invoke-IntuneWin32AppTest defaulted -Architecture to x64, which Windows on ARM refuses: there is no x64 PowerShell host there, and the agent runs Win32 detection and requirement scripts in the native ARM64 host when the rule's "run as 32-bit" option is off (Findings, "Windows on ARM"). Every example in the help had to be given -Architecture arm64 by hand on such a device. The parameter now has no default. Left out, the commands resolve it with Get-IslHostArchitecture, a new private helper that returns arm64 on an ARM64 device and x64 elsewhere, which is the host the agent would use. Explicit x64 and arm64 keep naming one host each and are still refused on the other CPU; the result's Architecture field reports the host that ran. The three tests that asserted the x64 default now expect the device's own 64-bit host, so the Windows on ARM job exercises the same assertion.
fadwen
left a comment
fadwen
left a comment
There was a problem hiding this comment.
Notes on the lines whose reason the diff does not show.
| # Left out: the device's 64-bit host (x64, or arm64 on Windows on ARM), the agent's default | ||
| [ValidateSet('x86', 'x64', 'arm64')] | ||
| [string]$Architecture = 'x64', | ||
| [string]$Architecture, |
There was a problem hiding this comment.
No default expression on the parameter, resolved in the body instead, for two reasons. [ValidateSet] is not applied to a default, so an empty default passes; and PlatyPS would print a default expression such as (Get-IslHostArchitecture) verbatim in the help's DefaultValue, where an empty value with the description explaining it reads better. Same in the other two commands.
| Write-Verbose "Starting $($MyInvocation.MyCommand.Name) for $($PSBoundParameters.Keys -join ', ')" | ||
| # The agent's default host is the device's 64-bit one: arm64 on Windows on ARM, where no x64 | ||
| # host exists, and x64 elsewhere | ||
| if (-not $Architecture) { $Architecture = Get-IslHostArchitecture } |
There was a problem hiding this comment.
Resolved before $detectionSplat is built, so the dependency and supersedence flows and the result's Architecture field all carry the resolved value rather than an empty string that Invoke-IntuneDetectionTest would then refuse through its ValidateSet.
| param() | ||
|
|
||
| $osArchitecture = "$([System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture)" | ||
| if ($osArchitecture -eq 'Arm64') { 'arm64' } else { 'x64' } |
There was a problem hiding this comment.
A separate helper rather than Get-IslDeviceFact, which already derives the same value: that one also reads free disk space and memory through CIM, which the harness does not need on every launch. The OS architecture is the same test Get-IslHostPath makes, so the two agree by construction.
| } | ||
| $result = Invoke-IntuneDetectionTest -Path $script:Detect | ||
| Should-Invoke Invoke-IslScriptRun -ModuleName IntuneScriptLab -Exactly -Times 1 -ParameterFilter { | ||
| $Architecture -in 'x64', 'arm64' |
There was a problem hiding this comment.
The parameter filter accepts either 64-bit host and the exact value is asserted on the result instead, because the filter runs in the mock's scope where the test file's $script:Native is not reliably visible. The same pattern replaces the literal 'x64' in the requirement and app test suites, so the arm64 CI job runs the same assertions as the x64 one.
| ```yaml | ||
| Type: System.String | ||
| DefaultValue: x64 | ||
| DefaultValue: '' |
There was a problem hiding this comment.
Empty DefaultValue is what Update-MarkdownCommandHelp writes for a parameter without one (compare -Credential in the same file), so a later full help build does not change this line.
1 participant
Summary
Invoke-IntuneDetectionTest,Invoke-IntuneRequirementTestandInvoke-IntuneWin32AppTestdefaulted-Architecturetox64, which Windows on ARM refuses: there is no x64 PowerShell host there, and the agent runs Win32 detection and requirement scripts in the native ARM64 host when the rule's "run as 32-bit" option is off (Validation/Findings.md, "Windows on ARM"). Every example in the help needed-Architecture arm64added by hand on such a device, and a script written for an x64 machine failed on an ARM64 one before it ran anything.Left out, the architecture is now the device's 64-bit host:
x64on an x64 device,arm64on Windows on ARM. That is the host the agent would use on the same device, so the default follows the device instead of assuming one CPU.Changes
Private/Get-IslHostArchitecture.ps1(new): returnsarm64on an ARM64 device andx64elsewhere.-Architecturehas no default; an empty value is resolved with the helper before the first launch.x64andarm64still name one host each and are still refused on the other CPU; the result'sArchitecturefield reports the host that ran.x64default expect the device's own 64-bit host, andInvoke-IntuneDetectionTestgains one;Tests/Unit/Private/Get-IslHostArchitecture.Tests.ps1checks the helper names a hostGet-IslHostPathresolves to System32.DefaultValueis empty.CHANGELOG.md: Changed entry under Unreleased.Verification
Get-IslHostArchitecture,Get-IslHostPath, the three command suites andModule.Contract: 81 passed on PowerShell 7.6.6; the same minusGet-IslHostPathon Windows PowerShell 5.1: 76 passed. Full unit suite on PowerShell 7.6.6: 907 passed, 2 skipped; on Windows PowerShell 5.1: 904 passed, 5 skipped.Invoke-IntuneDetectionTest -PathandInvoke-IntuneRequirementTest -Pathwithout-Architecturenow run inSystem32\WindowsPowerShell\v1.0\powershell.exeand reportArchitecture: arm64; before this change both threw "No x64 PowerShell host on this Arm64 device".Build/Build-Help.ps1 -SkipUpdate: help valid, MAML rebuilt and committed. PSScriptAnalyzer (Error, Warning) clean on the four source files; no line over 115 characters.arm64.Notes
fix/batch-powershell-warning); merge that first.arm64.-Architecture x64still throws there.