Deployment fails due to file in use

[fubar-coder]

Copy of issue #694, because it was closed even though this problem is still unresolved and @Eilon ignores comments that it's still unresolved.

By @pekkah:

Any workaround for this problem when deploying to Azure web site from VSO build server vNext?

Error Code: ERROR_FILE_IN_USE
More Information: Web Deploy cannot modify the file 'AspNet.Loader.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 adding a restart azure website command before the deployment but this seems to be still creeping in too often.

[shirhatti]

@fubar-coder By design, ASP.NET Core locks file in use. The guidance on our part is to use AppOffline rule while deploying via WebDeploy. The ASP.NET Core Module in IIS understands the app_offline.htm and shutdowns the dotnet process that locks the files.

Through the various issues reported on the linked thread, we've improved the robustness of this feature. (I'll concede we haven't done a good job communicating it).

If you are still seeing file locking issues, we need a repro to help further investigate what is going on.

Are you deploying to Azure App Service? If not, can you provide the file versions for both ANCM (%SYSTEM32%\inetsrv\aspnetcore.dll) and ANCMv2 (%PROGRAMFILES%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll) deployed on your machine?

[fubar-coder]

The last time I saw this kind of error was while deploying from a Win 10 Pro (1803) to an IIS on a Windows Server 2012R2. The installed WebDeploy has the file version 7.1.1973.0.

I guess that it would be useful to ask the other people in the old thread too. I created this new thread out of despair to increase this problems visibility.

[shirhatti]

Can you share the aspnetcore.dll file version as well?

[fubar-coder]

@shirhatti It's 8.2.1991.0

[weng271190436]

Is it possible to stop the website first, deploy, and start the website again? I did this for our site on Azure App Service using an Azure DevOps release pipeline.

[BrightSoul]

I provide some help on a community forum and, occasionally, there are people complaining about how ASP.NET Core is advertised as a modern framework and all, and then its publishing story is sub-optimal. And they're absolutely right.

By design, ASP.NET Core locks file in use.

@shirhatti And that's fine, but you'll seriously have to consider a solution for us IIS people who want to achieve 0 downtime when updating our application. Not everyone lives in the Azure part of town and I don't want to be considered as a second-class citizen.

Here's a suggestion: support deployment slots in ASP.NET Core Module.

And this is how it might work:

• Connect to your website via FTP;
• Create two directories in the website root, named SlotA and SlotB;
• Publish you application files to the SlotA subdirectory, along with its web.config file;
• Publish another web.config in the root directory. Here's how it might look, it describes two deployment slots:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV3" resourceType="Unspecified" />
      </handlers>
      <aspNetCore>
         <slots>
            <slot name="Production" path="SlotA" match="https://www.example.org" />
            <slot name="Staging" path="SlotB" match="https://staging.example.org" />
         </slots>
      </aspNetCore>
    </system.webServer>
  </location>
</configuration>

• The ASP.NET Core Module can now handle multiple applications. For one, it starts the application in the SlotA subdirectory and routes requests for www.example.org to it.
• Now publish an updated version of the application to SlotB. The ASP.NET Core module notices a change in the directory and starts this application as well, and routes requests for staging.example.org to it;
• And finally, publish an updated version of the web.config in the root directory. The slots have been swapped like this. SlotB has now become Production.

         <slots>
            <slot name="Production" path="SlotB" match="https://www.example.org" />
            <slot name="Staging" path="SlotA" match="https://staging.example.org" />
         </slots>

• The ASP.NET Core Module notices the slots configuration has been swapped and, instead of restarting the applications, it just starts to route request for www.example.org to SlotB, while previously they were routed to SlotA.

And that's it. I can then script some commands to publish a app_offline.htm to the slot I want to update, then remove it, then update the web.config in the root to swap slots.

To improve it even further, each slot element could containt some configuration that stick to the slot, used to define enviroment variables like "CONNECTION_STRING".

[peter-dolkens]

@shirhatti - Here's an entire thread of people telling you that app_offline doesn't work, without extensive manual intervention:

#3793

It seems these two are duplicates, and this is a clone of an older, unsolved issue.

I've been getting it repeatedly while trying to update our first 2 services in Azure, so Azure isn't a magical fix either.

Can we expect any progress on this? Our company is looking to pivot to microservices right now, and we've got pressures to move to node.js because ".Net Core isn't mature" - issues like this don't help me make my case for preserving our current .Net based workflows.

If I'm publishing a .Net Core code, using Microsoft tools (Visual Studio), to a Microsoft platform (Azure) - I shouldn't be facing UX issues like this if you're serious about building a leading-class development platform.

These are the kind of issues I expect from Eclipse IDE + Java a decade ago, not Visual Studio and .Net Core in 2019

[macfarmw]

We are about to go to work on some kind of PowerShell work around to get past this problem. Shut down app pool, copy files, start app pool and so forth. There are several such suggestions on similar comment threads about this problem.
I agree with the other comments that this is an important issue. I really hope a reliable and easy to use option becomes available soon.

[naveedahmed1]

For heavy traffic websites, the dll files are locked for even much longer time despite of using app_offline.htm. Which increase downtime of the website during deployment. Rest of the files are uploaded instantly but we have to struggle for min 10-15 minutes just to remove the locked dll files and upload new one. The original issues was reported in 2015, and yet no reliable solution to this problem exists. :(

[chrdlx]

For heavy traffic websites,

Not even heavy traffic, I've been using Blazor Server Side in my own IIS, one user (myself), and using app_offline.htm shows an erratic behaviour...
Sometimes the app shuts down fine, and sometimes I have to wait 15, 30 seconds..... so weird....

[BrandonChurch]

If you are deploying with a fresh web.config, adding a "Delete Files" task targeting the current web.config prior to copying forces IIS to stop and releases the lock on the .dlls. If you're not deploying a fresh config you could move the current config to a temp location, copy your release files, then move the config back for the same effect.

[jonny7]

I experience the same issue with Windows 2012 R2 deployments as part of a Jenkins pipeline. It has been working fine for a period and now i'm consistently getting this error. We're using

<PropertyGroup>
  <EnableMSDeployAppOffline>true</EnableMSDeployAppOffline>
</PropertyGroup>

to no avail

[chrdlx]

Still having the same problem... today a file stayed locked for the whole night....
Maybe it's because we're deploying to a network drive.... We have 2 servers that point to the same network folder, so when we update that folder both servers run the same app.
I'm gonna talk to the team that handles networks.... it's probably related to this, since asp.net had shadow copy and files don't lock, if I understand correctly in .net core that mechanism doesn't exist.... so the webservers are locking the network folder.

[PhilippRoessner]

We are facing that issue since long time now. We are deploying 30+ environments simultaneously and 70% +/- are failing reliably. We created a powershell script to switch the AppPool to a Stopped Apppool but even that doesn't help and the deployment fails. We have to manually access all the failed systems, a few of them are hosted OnPremise, connecting via vpn / rdp to manually fix that. It is absolutely not acceptable and I expect at least a reliable workaround.

[ErcinDedeoglu]

Why microsoft developers can't resolve that issue? Is it so hard?

[Yaz-X]

not sure but i hit this issue and i've just added:

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

to the publish profile and it worked just fine!

[davidfowl]

Closing this as dupe of #3793 (mostly because the other one has more discussion).