azure-pipelines-tasks: IIS Deploy on premises fails with ERROR_FILE_IN_USE

Same problem here. .NET 5 web api running on premise. It looks like this is not something new by researching it… still didn’t find a solution though.

Can we have an update on this issue ? I am still having this issue and having to kill the app pool each time is quite annoying.

Same problem here… I am using .NET 5 and deploying on premises.

The problem by check the option “Take app offline” is that if the deploy fail, the api goes down 😦

@20shivangi No the docs don’t provide a real solution for us:

“The downside of course is that your site is unavailable during the deployment. This can be avoided by relying on a Staging slot instead of deploying straight to Production.”

We already have Staging Sites running but at some point we need to deploy to Production. In most cases the deployment works seamlessly without app_offline and we have no down time at all. In rare cases it fails, which we never had before 2.1. I remember having read that there were some shadow copy mechanisms in place before. MSDEPLOY_RENAME_LOCKED_FILES seems to do something similar but is only available for Azure. For us its important to be able to hot deploy an application also on premise without taking it offline. I understand that cloud is now first class citizen but this is a critical feature for on premise too.

Hi, if this might help, even with the AppOffline flag enabled we are getting this ERROR_FILE_IN_USE exception on-premise from time to time. It started since moving to .net core 2.2 with the AspNetCoreHostingModel flag enabled. This flag default to true since 3.0 .

From the data I gathered from diverse sources this problem has been fixed in Azure by renaming locked dll(s) , hence the ticket we opened here for on-premise support in webDeploy : https://github.com/microsoft/azure-pipelines-tasks/issues/13223

I am encountering this all of the sudden. Restarting the pools and retrying the deployment usually fixes it but thats a poor fix.

Please advise.

We are facing the same problem since upgrading to 3.1 from 2.1. (on premise, InApp hosting model)

It only occurs when some longer running requests are still going on during deployment. Its quite a regression not being able to reliably hot deploy the application.

MSDEPLOY_RENAME_LOCKED_FILES is really needed for on premise too.

As mentioned in doc : If you have enabled App Offline and you’re still seeing issues with files in use, there are two main possibilities:

1. The first is that the runtime is completely failing to detect App_Offline.htm
2. The second is that the runtime detects it, but it takes a while to kick in, and msdeploy is not waiting long enough for file locks to get releases

Please go through this doc once with the steps mentioned and let us know if this unblocks you

Please try using IIS Web App Manage task to stop the application pool before deploying and then start the app pool again.

- task: IISWebAppManagementOnMachineGroup@0
  inputs:
    IISDeploymentType: 'IISApplicationPool'
    ActionIISApplicationPool: 'StopAppPool'
    StartStopRecycleAppPoolName: 'Testpool'

- task: IISWebAppDeploymentOnMachineGroup@0
  inputs:
    WebSiteName: 'TestSite'
    Package: '$(System.DefaultWorkingDirectory)\**\*.zip'

- task: IISWebAppManagementOnMachineGroup@0
  inputs:
    IISDeploymentType: 'IISApplicationPool'
    ActionIISApplicationPool: 'StartAppPool'
    StartStopRecycleAppPoolName: 'Testpool'

We tried to this approach, it works on some deployments but not for all. We have more than 500 sites manage by Azure DevOps On-Permises. Our deployment may be locked by HTTP keep-alive connection, we have assumed StopAppPool should terminate all of IIS connections in that AppPool.

@keeehlan Sure. But this issue is almost 3 years old with no official help from Microsoft, you say you are doing everything right which is great but there is obviously bugs and you need a workaround. This has been working for me and other users in this thread and it takes 2 seconds to implement.

Have been facing this for months now, which is incredibly frustrating. Can we please, PLEASE have an equivalent of MSDEPLOY_RENAME_LOCKED_FILES be included in the msdeploy flags?