Dealing with locked files - Azure WebApps - Deployment
Ever encountered an error like this below while deploying your code to Azure webapps?
Microsoft.Web.Deployment.DeploymentDetailedClientServerException: Web Deploy cannot modify the file (some exe or dll) on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
If the answer to the above question is yes, then you are at the right place. You’re definitely going to get an answer to the above problem before the end of this article.
Issue statement: While deploying the code over azure webapps using Visual Studio or Octopus Deploy, we get an error saying certain files or dlls are locked by an external process. Hence, the deployment fails.
On further diagnosing the issue from App Diagnostics on Azure portal, we can get the exact number of times we faced this issue and also the possible solutions that can be implemented to resolve this issue.
So, let’s explore the possible solutions as per Microsoft Azure:
– Restart your application to release the lock
The de facto solution of every problem on the planet Earth! If anything is not working, try restarting it! Even Microsoft approves it! 😀
Though this just might not be the best solution for everyone suffering from this issue.
– Use AppOffline rule handler for .Net application
Yes, this should solve the problem for everyone but the reality is not we believe it should be. Though this is the most promising solution to this problem and it works for most of the people, still there’s a small proportion for whom this problem still occurs. Hence, there’s still scope of another solution.
– Use Zip Deploy instead of Web Deploy
Yeah, it’s a good solution. It might work for a lot of people. Yes a lot of people! But still it doesn’t fit well with everyone’s business and technical architecture. You may find more on this on this link: https://docs.microsoft.com/en-us/azure/app-service/deploy-zip
To be honest, I have used this method. And yes, it works like a charm! But it didn’t fit well in all the technical architectures.
In search of the most appropriate solution, I checked different technical forums, support tickets, blogs and even reach Microsoft Azure support.
Here are some the links I went through that helped me reach down to some of the most appropriate solutions:
– https://github.com/Microsoft/azure-pipelines-tasks/issues/1607
– https://www.koskila.net/fixing-the-error-web-deploy-cannot-modify-the-file-on-the-destination-because-it-is-locked-by-an-external-process/
– https://stackoverflow.com/questions/37918650/azure-web-app-deploy-web-deploy-cannot-modify-the-file-on-the-destination-becau
– https://developercommunity.visualstudio.com/content/problem/96145/error-code-error-file-in-use-more-information-web.html
Solutions proposed by Microsoft Azure Team:
– Run from Package
Run From Package is an exciting new feature which lets you run a Web App or Function App by simply pointing it to a zip file containing your files. To use it, just add an Azure App Setting called WEBSITE_RUN_FROM_PACKAGE, and point it to your zip (typically using a storage SAS URL).
This feature greatly reduces the chances of running into locked files issues, and also has a number of other benefits, as described on the link. https://github.com/Azure/app-service-announcements/issues/84
– Use AppOffline rule handler for .Net application
– Start/Stop Webapp during the Deployment
This is rather a solution that would work most of the time due to technical reasons of stopping the webapp before deployment and then starting the webapp after the deployment. But to be honest this is not one of the cleanest solutions and should be followed if all other solutions fail.
– Set MSDeploy parameter for renaming locked files in Application Setting.
You can set this Azure App Setting on your app:
MSDEPLOY_RENAME_LOCKED_FILES=1
This causes msdeploy to attempt to rename DLLs if they can’t be copied during deployment. This often works because even when DLLs are loaded, they can typically still be renamed. It renames them with a .delete extension, which it then cleans up on the next round.
More info: https://github.com/projectkudu/kudu/wiki/Dealing-with-locked-files-during-deployment
Final Thoughts
After running through all the solutions, two solutions stand out as the best choice:
– Use AppOffline rule handler for .Net application
– Set MSDeploy parameter for renaming locked files in Application Setting.