azure-pipelines-tasks: ##WARNING##:PowerShell Core (pwsh.exe) is not available on agent machine. Falling back to using Windows PowerShell (powershell.exe). This can cause reduced performance

After reading the commit referenced above, it seems the developers left a switch to force the IIS Web App Deploy task back to using 7zip for artifact extraction. Just add a pipeline variable “ADO_FORCE_USE_7ZIP” set to “true”.

This is a terrible way to introduce a breaking change. The version number of the Task should have been increased so we could at least choose the old behavior. We spent 2 hours last night trying to figure out why all our release pipelines started failing before finally finding the obscure ADO_FORCE_USE_7ZIP setting.

The logic to detect whether to use PowerShell or 7Zip should at least check to see whether Expand-Archive exists in PowerShell and revert to 7Zip if not. If that’s not possible we at least need a way to change the setting more easily.

I’ll also note that our servers are Azure-hosted windows server instances that were created as recently as December, and they don’t have the requisite version of Powershell to run this task. Seems like this change could easily cause problems for far more users than for whom it fixes the issue with UTF8 characters in filenames.

I can verify that the pipeline variable solved the same issue for us; however, we are running many locally hosted agents that will need powershell approved/installed, or we have many release pipelines that will need an edit. Will there be a fix for this issue so this isn’t work we have to do, or is it a permanent (breaking) change? CI/CD is broken for us at the moment.

Sorry for the inconvenience caused. We are working on fix which will solve both the issues 1) defaulting to existing 7 zip tooling and 2) Handling the special characters with msbuild packages. Only customers who are facing issues with special character in msbuild need to update their pipelines and add a special variable “ADO_FORCE_USE_PSUNZIP” with value ‘true’, other customer does not need to update their pipeline, their scenario should work fine as it was working till last week. Even for customer who has added pipeline variable “ADO_FORCE_USE_7ZIP” or installed PS core, there should not be any change required, their scenario will continue to work without any pipeline / task update. We are already in process of rolling out the new fix with 0.184.1 version of task. It will reach to all customer within next three days. Thank you for support

Looking at #14626 is still appears that they are going to force/require that we add a pipeline variable: ADO_FORCE_USE_PSUNZIP in order for the current IIS Web App Deploy step to work properly…Complete hack IMO. Its going to require Admins to update every pipeline currently that currently uses the IIS Web App Deploy action.

Also, It appears the PR was merged into master. Can an Op please respond with an ETA, when this hack will be in Production?

FWIW I read that PR differently; I think all your pipelines that do not declare any hacky variables will work as they did before. Only if a pipeline is run with ADO_FORCE_USE_PSUNZIP=true will the extraction task use PowerShell, otherwise it’ll use 7zip as it did before the breaking change. Users who are experiencing the original issue Azure devs tried to fix (UTF characters in filenames) will need to add that variable to their pipelines in order for them to use PowerShell Expand-Archive. Hoping I’m right here.

I do like how the status of this ticket is clearly being updated but no one’s bothered to answer any of the questions yet.

Surely this isn’t complex to fix? Either roll back the change or issue some workaround guidance or do a patch to have it default back to 7zip if Powershell Core isn’t installed.

This also broke all of our release pipelines and has delayed a production release. Are you really not going to roll back this change? Installing the powershell core requires taking production machines offline and scheduling a maintenance window (causing further delays).

I would simply like a answer as to whether or not this is going to be fixed so the the IIS Web App Deploy activity functions properly as it did before?

I have the same situation as ebcdavid- CI/CD is broken at the moment. Applying this workaround all over Devops is not a pleasant experience. Is there a timeline for a solution?

The thing that the developer called “experimental” in the PR is now the official accepted way to back out the breaking change to this task. Good times.

Also, do these tasks not have incrementable version numbers? Azure tells me that the IIS Web App Deploy task is version 0, with no other versions available. If this change doesn’t warrant a version bump, retaining the old version that doesn’t use Expand-Archive, I’m not sure what does.

This change to use Expand-Archive instead of 7zip broke the IIS web app deploy task on all my servers. Please fix or revert it.

The deployment of 0.184.1 has been completed, as stated with previous comment, existing pipeline should work as expected and defaulted to use 7 zip

Official responses notwithstanding, there appears to be a PR to back this out by reversing the sense of the change - keeping PowerShell as a method of archive extraction but making 7zip the default. https://github.com/microsoft/azure-pipelines-tasks/pull/14626

-edit- please note I am not speaking for the Azure devs here

I have the exact same situation as @ebcdavid. As a matter of fact, we have to cancel our Production deployment because we saw this issue surface all of a sudden. Do we have a timeline for a permanent fix for this? Also, if we could tag such breaking changes to a different major version so as to be backward compatible. I didn’t find any way to specify the old working version in release pipelines. Thanks.

@pixelnix we will update the read md once our new solution reaches to all customers.

So basically if we’re paying for enterprise software we get all the breaking changes rolled out to us first, without proper updates or documentation or even a way to revert to an earlier, working version of the task?

We’ve been having the same issues as described here: https://github.com/microsoft/azure-pipelines-tasks/issues/14595#issuecomment-800602330

Previously this task was using 7zip for the deployment, now as of this update it always tries to use Powershell Core without ensuring that it’s installed on the machine. The fallback behaviour of using Windows Powershell is broken because the expand-archive command does not exist in Windows Powershell.

In short, if you must do updates that override existing functionality (e.g. stopping the use of 7zip) please could you at least make sure that the fallback for your new approach actually works.

File extraction commands exist in Windows Powershell so it shouldn’t be difficult to substitute those for expand-archive if the task falls back to using Windows Powershell.

It definitely appears as though this bug was introduced in: https://github.com/microsoft/azure-pipelines-tasks/commit/92ae148a02b1a174cc212222f9d92b07dc536ea6

The problem continues,

but I managed to get around it by installing PowerShell Core 7.1 on my server

# download the installation code
$code = Invoke-RestMethod -Uri https://aka.ms/install-powershell.ps1
# turn it into a function
$null = New-Item -Path function:Install-PowerShell -Value $code
# run the function
Install-PowerShell -UseMSI -Quiet

So, i restarted the server and ran another deploy, and finally works fine!