-
Notifications
You must be signed in to change notification settings - Fork 243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The 'Expand-Archive' command was found in the module 'Microsoft.PowerShell.Archive', #3522
Comments
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:ltsc2022
on Windows10 when using HyperV.It does happen When using
baseimage:2004
on Windows10 in process mode.It does NOT happen when using
baseimage:ltsc2022
on 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.Archive
intoC:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\6.0.16\AppHandling\Compile-AppInNavContainer.ps1
at 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: