aspnetcore: Deployment fails due to file in use

To update everyone, we confirmed that the theory above is correct: the case sensitivity bug is a regression in ANCM’s newer version, and that version got deployed to Azure App Service in December, causing users to suddenly hit this.

The plan is to get an ANCM fix from the ASP.NET Core team and deploy it to App Service. There is no ETA yet, but it should happen sometime in January.

Likewise with us, this issue cropped up on Friday last week and has blocked us from deploying since then…

I’m using Visual Studio 2015 Update 3 to publish a asp.net core 1.1 / .net framework 4.5.2 site to IIS. It drops down App_Offline.htm which does not take down the site. If I rename it on the server to app_offline.htm the site comes down.

Tentative deployment ETA is between 24th and 30th. Deployment happens gradually over the many scale units, so not everyone will get the fix at the exact same time.

@davidebbo “The plan is to get an ANCM fix from the ASP.NET Core team and deploy it to App Service. There is no ETA yet, but it should happen sometime in January.” – Let us know when an ETA is ready on this 😃

Here’s our workaround in Powershell that we’re using for now as part of our CI/build process. Special thanks to @appveyor guys for help with this:

$username = $env:deployusername
$password = $env:deploypassword
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username,$password)))
$Headers = @{
  'Authorization' = ('Basic {0}' -f $base64AuthInfo)
  'If-Match'      = '*'
}
$apiUrl = "https://YourAzureWebsite.scm.azurewebsites.net/api/vfs/site/wwwroot/app_offline.htm"
$filePath = "app_offline_tmp.htm"
Invoke-RestMethod -Uri $apiUrl -Headers $Headers -Method PUT -InFile $filePath -ContentType "multipart/form-data"

This makes use of the Kudu REST API to HTTP PUT the correctly cased app_offline.htm file in place. We have WebDeploy configured to remove any files not in the deployment, so it automatically removes the file as part of the deployment. You may need to repeat the step using a HTTP DELETE to remove the file after your deployment as finished if you’re not using this mode.

I am deploying using the “Azure Web App Deployment” task in VSTS, as described in this blog post: http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

Is there a way to specify the <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> using that method?

Happening to us as well - msdeploy to Azure. Glad to see it’s mysteriously started for a number of people at the same time - and it’s not just us - but not super reassuring overall!

Try setting MSDEPLOY_RENAME_LOCKED_FILES=1 in the Azure App Settings for your app.

@davidebbo

whether issue refers to Azure App Service or some other hosting

Azure App Service.

whether people have tried changing the app_offline casing as discussed above. Seems several people reported success there.

Changing App_Offline to app_offline fixes the issue - this file is created via webdeploy automatically with the ‘App_Offline’ casing as part of deployment, which is the crux of the issue.

My team also encounters this problem, almost every time deployment fails due to locked file. Needs to restart every app in azure and re-run deployment. We are using Octopus Deploy.

@davidebbo this doesn’t seem to resolve things.

I assume this is related to a change on the Azure side of the fence? A lot of people (especially on the aspnet slack channel) have had this issue all crop up at the same time.

@BenBarreth Is there something similar applicable to non-Azure?

@jdshkolnik The update has been available for download at https://www.microsoft.com/net/download/core#/runtime This is a direct link to the download.

Seems to be working now. From report it took over one year to get this fixed. I would’ve though deployment issues get higher priority :p

@henningst See https://github.com/aspnet/AspNetCoreModule/issues/50#issuecomment-271381892 for a way to check.

Thank you, for me it just started working 😃

If I understood correctly there is no workaround on our side until an update is available on ANCM (https://github.com/aspnet/AspNetCoreModule/issues/50). App services should be updated by the azure team.

@ctolkien

Changing App_Offline to app_offline fixes the issue

Where do I change this? I do MSDEPLOY directly from Visual Studio to Azure.

I still have this issue even when setting the MSDEPLOY_RENAME_LOCKED_FILES = 1 in my configuration. It is nearly impossible to update the build on my server now. This just started happening a few days ago.

Same here. Looks like it only affects sites with Always On = true, but that’s is not for sure.

not that I know of sorry @jdshkolnik

I was able to solve this issue by adding an Azure appsetting of

MSDEPLOY_RENAME_LOCKED_FILES = 1

… as described here: https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment-260946957

YMMV

No, the file has this instead: <WebPublishMethod>FileSystem</WebPublishMethod>

Here’s the command line from the output window: Executing command ["C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:manifest='C:\Users\yves\AppData\Local\Temp\PublishTemp\obj\SourceManifest.xml' -dest:manifest='C:\Users\yves\AppData\Local\Temp\PublishTemp\obj\DestManifest.xml' -verb:sync -enableRule:DoNotDeleteRule -retryAttempts:20 -disablerule:BackupRule]

@brandonmartinez, Restarting a website won’t help, as a production website will keep receiving requests, which will therefore relock the files. The only reliable way, currently, to update a both IIS and Azure websites is to shut down the web site’s application pool, then update the files, and then restart the website. Just follow @GuardRex’s link for more details.

However, we shouldn’t need to muck about with custom deployment scripts when working under default conditions with VS2015.

Hopefully the new HttpPlatformHandler infrastructure (which no longer needs an AspNet.Loader.dll) will be a bit more forgiving, but I’m not holding my breath here. We’ll probably get another locked .dll.