Azure website publish fails file in use

3
votes

I have a web application that I'm publishing to an Azure website. Sometimes it will publish with no issues. However, more often than not it will fail on a particular binary file (one of the business logic dlls) stating that the file is in use. After a quick google; it seems this means the file is in use on the server side. Which is odd as there are certainly no requests occurring against this web app at the time.

Is there some configuration option I need to set somewhere to force unloading of dlls? I've published Azure websites before and never seen this.

6
web-applicationsazurepublishazure-web-app-service
you could also use deployment slots to get around this problem. create a new deployment slot with production settings and deploy to a fresh new instance and then just swap. – neo112

6 Answers

2
votes

We had a similar situation once. It was resolved using following steps.

  • Stop the site from the portal

  • FTP into site using client such as FileZilla. You can get the FTP url & credentials from publish profile by looking for publishMethod="FTP" section.

  • Navigate to site/wwwroot folder

  • Delete the locked file(s)

  • Start the website

  • Redeploy the site immediately from deployments tab in portal.

1
votes

You should learn a bit about IIS and Web Deploy first.

Take a look at this SO Question is it basically describes the problem you have. In general it is a bit strange to have the assembly in use. Don't know the exact reason for this, but it lays somewhere in your assembly and, more importantly how it is being used.

As a suggestion - recycle the site before deploying (stop and start). Or try to deploy when the site is Stopped (which I doubt will be possible).

1
votes

Check out How to take web app offline while publishing for a possible solution. Basically including

<EnableMSDeployAppOffline>true</EnableMSDeployAppOffline>

in your pubxml file should alleviate the problem. However note that this might not work properly in all cases, especially for ASP.NET Core as evidenced by this thread on GitHub.

0
votes

The only solution that worked for me: delete the site and then redeploy (with the same name). FTP creds continued to work.

Other things I tried that didn't work:

  • Stop website and attempt to delete (or rename) the locked assembly via FTP or via Kudu command line. Got access denied error Kill w3wp via Kudu. Assembly remained locked. Rename DLL to a different file and redeploy. Somehow app wouldn't start up saying that it couldn't access the locked file, even though none of the other assemblies should be no longer be referencing it.
0
votes

There is multiple type of solution you can do it

  1. delete the existing file from azure.

  2. change the azure configuration settings

    MSDEPLOY_RENAME_LOCKED_FILES = 1

  3. if you dont want to delete the file then you can stop the service For example (Webjobs).

    WEBJOBS_STOPPED = 1

0
votes

Apparently the App_Offline.htm file that gets uploaded to your server while the publishing happens should actually be named app_offline.htm (i.e. lowercase). The system not recognizing the file in a case insensitive way is a bug (recognized at some point in this GitHub issue).

So if adding <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> to your .pubxml file doesn't work, and neither does restarting the Azure web app, try renaming App_Offline.htm to app_offline.htm on the server (and possibly publishing again). It should work.

PS: This bug was supposedly fixed in .NET Core in January 2017 (see the linked issue), but I couldn't figure out if the problem was the .NET version in Azure or in the upload PC, or something else (this thread didn't help me). In the meantime it seems like the problem is indeed fixed since it never happened to us again.