azure-pipelines-tasks: Azure App Service Deploy fails for .net core 2.0 with ERROR_FILE_IN_USE
I am trying to deploy an Asp.Net Core 2.0 web app to Azure App Service and receive this error
2017-09-07T15:20:07.7379097Z ##[section]Starting: Deploy Azure App Service
2017-09-07T15:20:07.7569101Z ==============================================================================
2017-09-07T15:20:07.7569101Z Task : Azure App Service Deploy
2017-09-07T15:20:07.7569101Z Description : Update Azure Web App Services, Web App On Linux , Function Apps, Mobile Apps using Web Deploy / Kudu REST APIs
2017-09-07T15:20:07.7569101Z Version : 3.3.14
2017-09-07T15:20:07.7569101Z Author : Microsoft Corporation
2017-09-07T15:20:07.7569101Z Help : [More Information](https://aka.ms/azurermwebdeployreadme)
2017-09-07T15:20:07.7569101Z ==============================================================================
2017-09-07T15:20:11.9902809Z Got connection details for Azure App Service:'██████████████'
2017-09-07T15:20:16.5780995Z [command]"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package='d:\a\r1\a\██████████████\drop\██████████████.zip' -dest:auto,ComputerName='https://██████████████.scm.azurewebsites.net:443/msdeploy.axd?site=██████████████',UserName='********',Password='********',AuthType='Basic' -setParam:name='IIS Web Application Name',value='██████████████' -enableRule:AppOffline -retryInterval:6000 -retryAttempts:10 -enableRule:DoNotDeleteRule -userAgent:VSTS_e29e8f6a-6b5e-463d-ba6e-72dd7866010e_release_10_50_99_1
2017-09-07T15:20:17.1910281Z Info: Using ID '████████████████████████████████████' for connections to the remote server.
2017-09-07T15:20:21.1058805Z Info: Using ID '████████████████████████████████████' for connections to the remote server.
2017-09-07T15:20:27.0283815Z Info: Updating file (██████████████\appsettings.Development.json).
2017-09-07T15:20:27.0283815Z Info: Updating file (██████████████\appsettings.json).
2017-09-07T15:20:27.0283815Z Info: Updating file (██████████████\Connected Services\Application Insights\ConnectedService.json).
2017-09-07T15:20:27.0283815Z Info: Updating file (██████████████\██████████████.Contract.dll).
2017-09-07T15:20:27.0283815Z Info: Updating file (██████████████\██████████████.Contract.pdb).
2017-09-07T15:20:27.0283815Z Info: Updating file (██████████████\██████████████.deps.json).
2017-09-07T15:20:27.0283815Z Info: Updating file (██████████████\██████████████.dll).
2017-09-07T15:21:24.7852633Z ##[error]Failed to deploy web package to App Service.
2017-09-07T15:21:24.7862628Z ##[warning]Try to deploy app service again with Rename locked files option selected.
2017-09-07T15:21:24.7862628Z ##[error]Error Code: ERROR_FILE_IN_USE
More Information: Web Deploy cannot modify the file '██████████████.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.
2017-09-07T15:21:24.7862628Z ##[error]Error: C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe failed with return code: 4294967295
2017-09-07T15:21:26.2210992Z Successfully updated deployment History at https://██████████████.scm.azurewebsites.net/deployments/501504797684782
2017-09-07T15:21:26.2321177Z ##[section]Finishing: Deploy Azure App Service
I’ve tried some workarounds from similar issue without any luck https://github.com/Microsoft/vsts-tasks/issues/1607
Any ideas on what should I do to fix this?
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 23
- Comments: 129 (29 by maintainers)
This is definitely a hack/workaround, not a very satisfying solution.
New Version of Web Deploy is used in App Service Deploy to avoid FILE_IN_USE as per web deploy team recommendation. If you still face
FILE_IN_USEerror, we recommend you to move fromWeb DeploytoRun From Package.Run From Packagesupport is added in4.*task version of Azure App Service Deploy task.Run From Package helps in avoiding the FILE_IN_USE error.
If you face the below issue,
Publish using zip deploy option is not supported for msBuild package type., please follow the steps provided here to change the package format.#8710 - Added recommended message in the error logs to move from Web Deploy to Run From Package.
Closing the issue as the above recommendations should fix this. Please feel free to re-open or start a new thread, if any assistance required.
@frankfuu , Can you please edit the build as follows:
In Build Solution task, change the MSBuild Arguments to
/p:DeployOnBuild=true /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl="$(System.DefaultWorkingDirectory)\\WebAppContent"Add Archive Task and change the inputs as follows:
Root folder or file to archiveto$(System.DefaultWorkingDirectory)\\WebAppContentPrepend root folder name to archive pathsoptionPlease reopen, stopping the website is not what one should be recommend to do… We have production apps depending on 100% uptime.
This sure seems like a common problem for there not to be any solution, or feedback from the VSTS team to at least say, “We’re working on it.”
@vincentdass It works around the core issue. A workaround is a temporary solution to a more fundamental problem. The fundamental problem is by default this task fails without a lot of monkeying around with the settings. Do you expect users in the future to simply search for a solution, find this post, and apply your workaround whenever people come across this in the future?
This is hitting people pretty frequently so how about Microsoft making an effort to reproduce it and doing the right thing with this? its close to a “show stopper” for some of us.
Don’t lose sight of the fact that MS are competing with the likes of AWS too…
There are at least three versions of this issue floating around, all with workarounds that don’t work for everyone. It became an issue again with .NET Core v2 release time… perhaps the thing that changed has something to do with it? Having to change your build process and endure a lot of pain with every release isn’t great for productivity.
I did that and it had no effect.
@PaitoAnderson I got a repro. What I found is that for some version VS, ANCM did not get the file change notification when app_offline.htm file was deployed by webdeploy. If manually dropping app_offline.htm, the deployment works. And Unfortunately, webdeploy never tried to redeploy the app_offline.htm during retry. I’m working with WebDeploy developer to see whether we can redeploy the app_offline.htm during retry and may be change ANCM to periodically scan the app_offline.htm file instead of purely relying on file change notification. Will update the thread about the progress.
Having this configuration in asp.net core 2.0 project works fine for us now
@PrimeHydra Understood. Thanks for working what worked for you.
I just wanted to make sure that your comment about
WEBSITE_RUN_FROM_ZIPwould not be interpreted by others as an issue with that feature (which it isn’t).Was hitting this issue trying to deploy a .NET Core 2.0 Azure Function. Tried WEBSITE_USE_ZIP=1, didn’t help. Tried checking Take App Offline, no joy.
What worked for me: Checking Publish Using Web Deploy and Rename Locked Files, then creating a new deployment. (Like jonathaneckman said, Redeploy won’t work because it won’t pick up your changes to the release definition.)
@jsheetzati VSTS consuming zipdeploy is work in progress and we will let you know once it is ready.
@davidebbo What is the recommended way to “Tell vsts to use zipdeploy (and not use app_offline)”? Is there a way to do this with the Azure App Service Deploy task?
@PaitoAnderson can you email me details (david.ebbo (at) microsoft.com), including the test site name and the zip url? We’ll figure out what’s going on.
@PaitoAnderson (and others) I have some potentially good news for things to come in the next week or so:
WEBSITE_RUN_FROM_ZIP=1, not the external URL), ZipDeploy changes its behavior to use the passed in zip file for Run-From-Zip (instead of just expanding it towwwrootis it normally would -wwwrootis read-only in this case).I know this sounds a little complicated, but bottom line is that in theory, to get things working with .NET Core and VSTS, all you have to do is:
WEBSITE_RUN_FROM_ZIP=1Does that make sense?
Yes, I’ve set EnableMSDeployAppOffline to true in the publish profile and it had no effect whatsoever.
@davidebbo @IvanAlekseev
VS 2017 Enterprise, 15.5.6.
I’ve just encountered this problem after my first experiments in publishing .Net Core Web Apps to Azure. The problem is intermittent for me. I published a simple app this morning and (other than two frustrating but unrelated problems https://github.com/aspnet/JavaScriptServices/issues/1330 and https://github.com/aspnet/JavaScriptServices/issues/1282) had no problem. I published the app several times over the course of an hour as I made tiny tweaks to it (cosmetic).
I then went out for an hour, came back made another small tweak and tried to publish whereupon I hit this locked assembly issue.
I stopped the app in azure and it then published fine, I made a small change and published without stopping it and that too went fine.
I have to say, the presence of this problem strikes me as rather incredible given the fundamental nature of what we’re discussing here. If publishing to Azure using the latest MS tools fails like this then what is going on at Microsoft? This issue seems to have been around for quite a while and it’s not being treated as a priority 1 bug?
I have no idea what goes on under the hood with a publish, but surely part of the protocol must involve a request to stop the app as one of the first steps?
I’m interested to know too if the problem is in VS 2017 or Azure, does anyone at least know this much?
Is this officially regarded as a bug by Microsoft?
Thanks.
I got stuck behind the same issue deploying my .NET Core 2 app to an app service using every variety of work around in this thread.
Make sure you queue a new release if you change your release task using the suggestions above. Using redeploy will not pick up changes to your task.
hi @niadak Yep, it seems to be working so far! I’m hoping to kind of go back and see how many times it actually did retry.
@frankfuu , Can you please make below changes to your task?
If you are still facing the issue, we suggest you to stop the app service, deploy and start the app service. For zero down-time deployment, you can deploy to your staging slot and swap it with production.
Azure App service Managetask can be handy here.