The 'Expand-Archive' command was found in the module 'Microsoft.PowerShell.Archive', #3522
Comments
|
The module is there - but for some reason, your session is looking for the en-GB version: The module is there in en-US. What does this return in your container: Both in BC23 and BC24? and what does this return: both in BC23 and BC24? |
|
I have earlier seen people having issues with culture - let's see if we can fix this now |
|
if you add -locale 'en-US' when starting the container - does it work then? |
|
similar issue #3330 |
|
Similar problem here, it is expecting a de-DE folder in the Powershell Module. Edit: Can confirm it works on 6.0.15 |
|
I think I have found the root cause. It seems like this fix (PowerShell/Microsoft.PowerShell.Archive#46) never made it into the Windows Containers - even though it is 7 years old... Now, the reason why 6.0.15 (and earlier versions) have worked is that they don't use a configurationName when creating a PowerShell session to the container. That however means that it cannot create a PS7 session - only a PS5 session. Now, I am using a configurationName, which causes the UI culture to be different. Looking at #3330 - this also could happen before. The fix could be to patch the powershell archive module during startup. and place them in a local file called AdditionalSetup.ps1 If you can confirm this works, then I will check this in |
|
Adding the The The The session data differs for V23 and V24, V24 uses powershell7 and V23 uses default powershell. For V24 WinRM has been turned on on that machine. So I turned it off and ignored the error. Session V23 with WinRM turned off. (Turning WinRM off did not fix it.) All four combinations (23,24 and powershell, pwsh) return en-US when running a powershell with the bc-image just using docker. Host returns |
|
Grrrr. |
|
Ok, then maybe |
|
Another thing I would like you to try is to set $bcContainerHelperConfig.useWinRmSession = 'always' in the latest 6.0.17 preview without the above overwrite and tell me if that fixes the issue. |
|
Success! |
|
Thank you! While using just 6.0.17-preview1193 without the overwrite does not seem to work on my end, it does work with the overwrite. |
|
Setting json config. "always" fails. This fails no winrm set always This fails no winrm set never Host WinRM enabled, set "always" success Host WinRM enabled, set "never" fails WinRM enabled, setting is default, fails |
|
OK - I also expect that setting "usePSSession" to false then works without the override. It seems like the problem is only on getting a session using the containerId with a configurationName set I think I have enough to make a fix. |
|
Shipped in preview |
|
Please test the latest preview, thanks |
|
Looks good here! |
|
Looks good, "BcContainerHelper version 6.0.17-preview1194" is running fine with defaults, no WinRM on host. |
|
shipped 6.0.17 |
Describe the issue
I'm getting this error from
Compile-AppInBCContainer, this only happens with V23 (not V24 or V25, haven't tested earlier).Google says this is likely a version skew. ... Hmmm.
It happens with
baseimage:ltsc2022on Windows10 when using HyperV.It does happen When using
baseimage:2004on Windows10 in process mode.It does NOT happen when using
baseimage:ltsc2022on Windows-server-2022 in process mode.It started in 6.0.16, locking the agents on 6.0.15 gives no error.
Is that a DLL copied from the host ?
I did this on a Win11 agent.
Also nothing from a default shell in the image.
But If I add the command
Import-Module Microsoft.PowerShell.ArchiveintoC:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\6.0.16\AppHandling\Compile-AppInNavContainer.ps1at line 313,I get this:
in this:
Scripts used to create container and cause the issue
Full output of scripts
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
BTW:
There was an error creating your Issue: body is too long (maximum is 65536 characters).The text was updated successfully, but these errors were encountered: