IIS Web Application Management

[fthkucuk]

Hi,

I got an error iis web manage task cause apppool already stopped so I tried to additional appcmd.exe commands for use exit 0 or set errorlevel=0 but it didn't work. I tried something else like capture2 but I didn't see this command in log (You can see Capture 3). It seems to don't work additional arguments for web application management tasks. I'm using Azure DevOps Server 2019 Update 1

[SumiranAgg]

@fthkucuk The issue is happening because appcmd.exe throws an error if the app pool you are trying to stop is already stopped. Ideally we should check the status of the app pool before executing the command. This is an enhancement. For now you can mark this task to continue on error to avoid failing the pipeline.

[github-actions]

This issue is stale because it has been open for a year with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[ssinfod]

I think this enhancement should be implemented.
The task should offer an option to check if the pool is already stopped.

Is the code source of the task available somewhere ? (If yes, What file ?)
Is it possible for me to adapt it and ask for a PULL request ?

[rschindhelm-haba]

I agree that the task should not return an error if the application pool is already in the stopped state.
The "continue on error" option would proceed even if there is an actual error, e.g. wrong application pool name, and could be more harmful then helpful.

[ldsenow]

Can we reopen this issue?

We see warning sometimes after deployment. I am worried about the "continue on error" option one day will cause false positive.

[aaron-3dn]

As a simple workaround for the original issue, you can start the apppool before stopping it.

Starting an apppool which is already running does not generate an error.

[brs713]

Sooooo... the desired behavior is stopping the app pool. If the result is that the app pool is stopped, so no change takes place, that's not an error. If the outcome is the same as the desired behavior, then returning an error code is a bug. Fix your bug.

If you make a DELETE API call and the resource doesn't exist, there's debate over returning a 404 or a 200, but no sane person would return a 500.

Return an exit 0 or a warning, but in no way is returning a stopped app pool for a request to stop an app pool an error.

This is not an enhancement; this is a bugfix.

[farinha]

As a simple workaround for the original issue, you can start the apppool before stopping it.

Starting an apppool which is already running does not generate an error.

This supports the point @brs713 is making. When the desired outcome has already been achieved and no change needs to take place... that's not an error. If anything it could be a warning, but definitely not an error.

Found this issue that deals with the same behavior but for the "App Command on Target Machine" task. It seems to have been dealt with a long time ago.
A brief look at the latest version of the task shows that it's still following that same logic:

if ((($appPoolState -like "Started") -and $action -like "start") -or (($appPoolState -like "Stopped") -and $action -like "stop")) {
    Write-verbose "Application pool '$appPoolName' is already in state of the action '$action'. Hence skipping the operation."
    return
}

Should something similar be done in this "IIS Web Application Management" task?

[dominikcip]

this one should be re-opened. This is definitely issue which needs to be solved