I am trying to deploy my app to an Azure WebApp slot but it seems that the file (Microsoft.Data.Edm.dll) it is trying to update is locked even though I have manually stopped the WebApp. I got the following error while deploying my app.
Web deployment task failed. (Web Deploy cannot modify the file 'Microsoft.Data.Edm.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.)
I tried on both VSTS web deploy task and manual deploy from Visual Studio, it returns me the same error message. I tried restarting the WebApp, setting the COR_ENABLE_PROFILING = 0 then 1 too but again, same error. The last resort that I didn't try is delete the WebApp and recreate again.. but i would like to know if there are other suggestions first before I do this desperate measure.
Thank you in advanced.
Restarting works better, stop just stops the http listener, restart restarts the running proces
Please try to use Resources explorer portal to full stop your web app. In this way, we can delete some locked files via FTP without anything running. For more details about how to full stop your web app, please refer to this article
As of time of this writing, if you are using Azure DevOps (VSTS) to deploy your application, you can select "Run From Package" in the "Azure App Service Deploy" task/step - this is available in version 4 of the task, under the "Additional Deployment Options" node.
This deployment option eliminates file locking issues as it provides atomicity, in that the application is pointed to the new zip file rather than deploying a bunch of loose files under wwwroot, some of which may be locked.
It provides you with a number of other benefits that you can read about it if you search and read about the feature.
HTH
Related
I'm having a problem with a locked DLL file while I tried to deploy with a Release Pipeline in Azure Devops.
The screenshot of the error is:
Output as text:
2021-03-31T17:43:18.2626492Z ##[error]Error Code: ERROR_FILE_IN_USE
More Information: Web Deploy cannot modify the file 'Microsoft.Data.SqlClient.SNI.x64.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.
Error count: 1.
It seems the problem is caused by a wrongly disposed .NET resource. (ex: unmanaged SqlConnection)
Anyway, I can't change the source code.
Here is my Release Pipeline.
Here are my questions:
Q1) I'm trying to use the "-RenameFilesFlag" (MSDEPLOY_RENAME_LOCKED_FILES) as described here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-rm-web-app-deployment?view=azure-devops
web.config file locked during Azure App Service Deploy task
How do I have to specify this argument ?
Do I have to fill the "Additional arguments" textbox ? I tried different values and I always get an
"Unrecognized argument" error.
Q2) If the "-RenameFilesFlag" is not available for this task.
Can I use the "Take App Offline" to unlock a file ?
Q3) On another post on StackOverflow, I saw a checkbox option specific to "Rename locked files"
Getting ERROR_FILE_IN_USE while using Web Deploy in Azure App Service Task v3
I don`t have this option in my task. Is it possible that I am confusing two type of Deploy tasks ?
MSDEPLOY_RENAME_LOCKED_FILES
As far as I know, this method only supports Azure Web APP service. This option is used to set the Azure App settings(cloud). It does not apply to IIS deployment(on-prem).
##[error]Error Code: ERROR_FILE_IN_USE
To solve this issue, you could try the following methods:
1.You could set the Take App Offline option in IIS Web Deploy task.
Here is a doc about Taking an Application Offline before Publishing
2.You could Stop your website before deploying the app and restart it after deployment.
You could add IIS web app manage task to stop and start the IIS Website.
For example:
Update1:
As ssinfod's comment: stop the application pool could solve this issue.
We can also achieve this in IIS web app manage task
We are deploying into azure using Octopus deploy. We are using it since more than a year, and suddenly we started (about 3 weeks ago) to get errors on few deployments.
Microsoft.Web.Deployment.DeploymentDetailedClientServerException: Web Deploy cannot modify the file 'msvcr120.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
We have the webapp running and always on and we have the app setting 'MSDEPLOY_RENAME_LOCKED_FILES' to 1 that in theory prevents this.
Does anyone knows if something was changed in azure or octopus?
There are a number of reasons files may be locked during deployment. You should be able to get an idea of what may be locking files by using the kudu process explorer, which you can access using the url {yoursite}.scm.azurewebsites.net.
In order to avoid the locking issue altogether, you could make use of slots to achieve a zero downtime deployment if that's an option for you. In this case you could stop the site or enable App Offline which should unlock any files and allow the deployment to succeed after which a slot swap will make the deployment live. App Offline is preferred over using MSDEPLOY_RENAME_LOCKED_FILES, but will take the application offline during the deployment. Octopus also has support for this as an option on the Deploy an Azure Web App step itself, so may be worth a try even without slots.
You can use custom pre/post deployment scripts as part of your Deploy an Azure Web App to make use of the Stop-AzureRmWebAppSlot, Start-AzureRmWebAppSlot and Switch-AzureRmWebAppSlot Powershell commands Azure commandlets to achieve the above.
An alternative may be to use zip deployments, however, the Deploy an Azure Web App Octopus step doesn't have first class support for this quite yet. It can still be achieved using a Run an Azure PowerShell Script along with a package references if this is what you are wanting to do.
We have a bug in our WebJob running in our live environment, I have identified the bug and fixed it, this I can verify in our Dev-environment. I published my WebJob as a "Azure WebJob" to our live environment but the bug i still present. To add to the confusion the bug now just occurs sometimes. So for some reason the old code is running somewhere sometimes.
Can someone please help me understand this?
I had a similar problem. We deploy using a stage environment in Azure and it turned out that the "old" WebJobs (running code with an old version of the entity framework model) where still running on the queue. These jobs where then fetching messages and consuming them. To add to the problem the exception was consumed in a try catch and the status of the WebJob was success.
Check if you have a stage environment (add -stage to the Webapp name) and if so go in to the Azure management portal and stop them.
Note, it is not enough to stop the Webapp, you must stop the WebJobs directly. This is done (in the new portal) under Settings->WebJobs and then right-clicking on the webjobs name selecting stop.
I spent ages looking into this problem. Turns out I had the web job project running in a console on my PC at work! No matter what I did on Azure the presence of this exe running and using the same storage for the web jobs meant that the old code running on my work PC picked up the jobs before Azure did. Easy fix: just make sure no exes are running outside of Azure!
In our case the web app was published to physical path /site/www instead of the default /site/wwwroot, because of this the Azure web portal interface adds the WebJobs to folder /site/jobs, but the webdeploy via VS or Azure are still trying to publish the webjobs inside the /site/www.
More details at Publishing WebJobs with Azure Pipelines
I setup continuous Azure Websites deployment over old Full Azure Portal. Each build failed because of error:
Exception Message: Web Deploy cannot modify the file
'Microsoft.ApplicationInsights.Extensions.Intercept_x64.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.
I'm able to run builds successfully when I stops the websites, but this have nothing to do with continuous integration. What is wrong?
I believe it was fixed in 0.13 AI SDK. Please try to use the latest version.
It is because ApplicationInsights is monitoring your performance and it is in use by IIS as long as your application is running, hence locked.
You have two options:
Take your site offline if you need to update this resource.
Or don't update this resource if it didn't change.
EDIT:
3rd option:
You could try if the AppOffline flag can help you, but my guess is no:
http://blogs.msdn.com/b/webdev/archive/2013/10/30/web-publishing-updates-for-app-offline-and-usechecksum.aspx
I have an on premise IIS instance that I publish to using web deploy. When I added Application Insights I get the following error.
(Unable to perform the operation ("Delete File") for the specified directory
("Microsoft.ApplicationInsights.Extensions.Intercept_x64.dll").
If I try to delete the file manually it says it is in use by the IIS Worker Process. Is there any way to reset the site or override the lock so that it can successfully publish? Or is there a way to not publish this file?
This is known issue and fixed is being worked on. We plan to deploy the fix with the next version of SDK release (0.13).
In SDK 0.12 the only workaround is to stop application pool which your web site is running on before running deployment, so locked modules will be unloaded and deployment procedure will be able to rewrite file(s).
And yes, this issue is prioritized to be fixed in 0.13.