New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Azure Web App Deployment error: Web Deploy cannot modify the file - ERROR_FILE_IN_USE #1607

Closed
AndreaPic opened this Issue Apr 29, 2016 · 122 comments

Comments

@AndreaPic

AndreaPic commented Apr 29, 2016

Hi,
I'm using Azure Web App Deployment Task in a step of continuous integration on Visual Studio Team Services in hosted environment.
Nightly are scheduled many rebuild of different app in a different build definition.
Every night some of this build definition goes in error in Web Deploy step whit this message:

Web Deploy cannot modify the file 'X' 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.

The file in use isn't ever the same but can change.
Can you help me ?
What can I do ?
There is a way to force stopping and restarting the app ?
Thank you
Andrea

@yaananth

This comment has been minimized.

Show comment
Hide comment
@yaananth

yaananth Apr 29, 2016

Member

image

could you try setting donotdelete flag?

Member

yaananth commented Apr 29, 2016

image

could you try setting donotdelete flag?

@AndreaPic

This comment has been minimized.

Show comment
Hide comment
@AndreaPic

AndreaPic Apr 29, 2016

I've set the "do not delete" flag and tomorrow I'll to see the output.
But I've a question about this flag.
What are "additional files" ?
Thanks
Andrea

AndreaPic commented Apr 29, 2016

I've set the "do not delete" flag and tomorrow I'll to see the output.
But I've a question about this flag.
What are "additional files" ?
Thanks
Andrea

@AndreaPic

This comment has been minimized.

Show comment
Hide comment
@AndreaPic

AndreaPic May 2, 2016

Hi @yaananth ,
In the last nightly build with "do not delete" flag active the problem did not occur.
I'll see the next nightly build and if it will still ok the problem could be solved.
Thanks
Andrea

AndreaPic commented May 2, 2016

Hi @yaananth ,
In the last nightly build with "do not delete" flag active the problem did not occur.
I'll see the next nightly build and if it will still ok the problem could be solved.
Thanks
Andrea

@AndreaPic

This comment has been minimized.

Show comment
Hide comment
@AndreaPic

AndreaPic May 3, 2016

Hi @yaananth ,
Past two nightly build and complete continuous integration has the same problem.
It seems that donotdelete flag didn't solve the problem.
The last problem is :

Web Deploy cannot modify the file 'Microsoft.CodeAnalysis.CSharp.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

Have you another idea ?
Thanks

AndreaPic commented May 3, 2016

Hi @yaananth ,
Past two nightly build and complete continuous integration has the same problem.
It seems that donotdelete flag didn't solve the problem.
The last problem is :

Web Deploy cannot modify the file 'Microsoft.CodeAnalysis.CSharp.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

Have you another idea ?
Thanks

@codito

This comment has been minimized.

Show comment
Hide comment
@codito

codito May 3, 2016

Contributor

@AndreaPic this issue is similar to #1233, can you please try the workaround mentioned there?

Publish-AzureWebsite doesn't support AppOffline option, the newer msdeploy based azure website deployment task will fix this issue.

Contributor

codito commented May 3, 2016

@AndreaPic this issue is similar to #1233, can you please try the workaround mentioned there?

Publish-AzureWebsite doesn't support AppOffline option, the newer msdeploy based azure website deployment task will fix this issue.

@AndreaPic

This comment has been minimized.

Show comment
Hide comment
@AndreaPic

AndreaPic May 9, 2016

Hi @codito @yaananth I've tried the solution mentioned but I've the "login" problem too.
Is the support for AppOffline option planned for "Publish-AzureWebsite" Task ?

AndreaPic commented May 9, 2016

Hi @codito @yaananth I've tried the solution mentioned but I've the "login" problem too.
Is the support for AppOffline option planned for "Publish-AzureWebsite" Task ?

@codito

This comment has been minimized.

Show comment
Hide comment
@codito

codito May 10, 2016

Contributor

@AndreaPic sorry, there isn't a way to fix AppOffline issue with this task. Can you please try the msdeploy based website deployment task? It is in preview at the moment, however you can use tfx-cli to upload the task to your account and use it. We will be glad to hear your feedback.

Contributor

codito commented May 10, 2016

@AndreaPic sorry, there isn't a way to fix AppOffline issue with this task. Can you please try the msdeploy based website deployment task? It is in preview at the moment, however you can use tfx-cli to upload the task to your account and use it. We will be glad to hear your feedback.

@codito

This comment has been minimized.

Show comment
Hide comment
@codito

codito May 10, 2016

Contributor

Just realized your account may not be enrolled into preview. Kindly drop an email to rm_customer_queries on the domain microsoft dot com if you don't see the task. /cc:@RoopeshNair

Contributor

codito commented May 10, 2016

Just realized your account may not be enrolled into preview. Kindly drop an email to rm_customer_queries on the domain microsoft dot com if you don't see the task. /cc:@RoopeshNair

@codito codito closed this May 26, 2016

@tebeco

This comment has been minimized.

Show comment
Hide comment
@tebeco

tebeco Jun 20, 2016

@codito is the issue fixed ? It's marked as closed but still occurs from vsts release

I'd like to keep release managment instead of powershell publishing if possible

I guess this issue should NOT be closed right ?

tebeco commented Jun 20, 2016

@codito is the issue fixed ? It's marked as closed but still occurs from vsts release

I'd like to keep release managment instead of powershell publishing if possible

I guess this issue should NOT be closed right ?

@codito

This comment has been minimized.

Show comment
Hide comment
@codito

codito Jun 21, 2016

Contributor

@tebeco this was closed because there is an msdeploy based alternative for this task available which supports taking app offline. Can you please try AzureRMWebAppDeployment?

There is no plan to support app offline in this task.

Contributor

codito commented Jun 21, 2016

@tebeco this was closed because there is an msdeploy based alternative for this task available which supports taking app offline. Can you please try AzureRMWebAppDeployment?

There is no plan to support app offline in this task.

@tebeco

This comment has been minimized.

Show comment
Hide comment
@tebeco

tebeco Jun 21, 2016

A ok. No pb ;)

Thx for the precision

tebeco commented Jun 21, 2016

A ok. No pb ;)

Thx for the precision

@sebvst

This comment has been minimized.

Show comment
Hide comment
@sebvst

sebvst Sep 7, 2016

Even if I enable "take app offline" the error occurs. In my case it is always msvcr100.dll that causes the problem.

Does anyone else have the same problem?

sebvst commented Sep 7, 2016

Even if I enable "take app offline" the error occurs. In my case it is always msvcr100.dll that causes the problem.

Does anyone else have the same problem?

@knoxitus

This comment has been minimized.

Show comment
Hide comment
@knoxitus

knoxitus Oct 23, 2016

@sebvst I have exactly the same problem that msvcr100.dll is locked by using the AzureRMWebAppDeployment build step, . Enbling or disabling "take app offline" has no effect.

knoxitus commented Oct 23, 2016

@sebvst I have exactly the same problem that msvcr100.dll is locked by using the AzureRMWebAppDeployment build step, . Enbling or disabling "take app offline" has no effect.

@asranja

This comment has been minimized.

Show comment
Hide comment
@asranja

asranja Oct 24, 2016

Contributor

can you mail the release logs to RM_Customer_Queries@microsoft.com. Make sure to keep the system.debug variable to true and enable the app offline feature.

Contributor

asranja commented Oct 24, 2016

can you mail the release logs to RM_Customer_Queries@microsoft.com. Make sure to keep the system.debug variable to true and enable the app offline feature.

@KrishnaAdityaB

This comment has been minimized.

Show comment
Hide comment
@KrishnaAdityaB

KrishnaAdityaB Nov 16, 2016

Contributor

Please set below setting on the app.
MSDEPLOY_RENAME_LOCKED_FILES = 1
Automating this is in backlog. Marking this thread as enhancement

rename_locked_files

Contributor

KrishnaAdityaB commented Nov 16, 2016

Please set below setting on the app.
MSDEPLOY_RENAME_LOCKED_FILES = 1
Automating this is in backlog. Marking this thread as enhancement

rename_locked_files

@dpodder

This comment has been minimized.

Show comment
Hide comment
@dpodder

dpodder Nov 22, 2016

@KrishnaAdityaB @RoopeshNair I've started hitting ERROR_FILE_IN_USE recently when deploying to staging slot using AzureRmWebAppDeployment (take app offline is set). Oddly does not happen when deploying directly to production; only happens when deploying to a slot.

Could you clarify what MSDEPLOY_RENAME_LOCKED_FILES = 1 is expected to do? Do the old files get deleted, after a rename? Alternatively, would you recommend adding a manual step to take the app offline prior to executing the deployment task?

dpodder commented Nov 22, 2016

@KrishnaAdityaB @RoopeshNair I've started hitting ERROR_FILE_IN_USE recently when deploying to staging slot using AzureRmWebAppDeployment (take app offline is set). Oddly does not happen when deploying directly to production; only happens when deploying to a slot.

Could you clarify what MSDEPLOY_RENAME_LOCKED_FILES = 1 is expected to do? Do the old files get deleted, after a rename? Alternatively, would you recommend adding a manual step to take the app offline prior to executing the deployment task?

@nickspiers

This comment has been minimized.

Show comment
Hide comment
@nickspiers

nickspiers Dec 3, 2016

I have the take app offline option selected, am not deploying to a slot but directly to production and am getting the ERROR_FILE_IN_USE.

nickspiers commented Dec 3, 2016

I have the take app offline option selected, am not deploying to a slot but directly to production and am getting the ERROR_FILE_IN_USE.

@YanivDa

This comment has been minimized.

Show comment
Hide comment
@YanivDa

YanivDa Dec 4, 2016

@asranja @KrishnaAdityaB MSDEPLOY_RENAME_LOCKED_FILES = 1 solved the issue.
Is this workaround a permanent solution? what is the effect of this parameter?

YanivDa commented Dec 4, 2016

@asranja @KrishnaAdityaB MSDEPLOY_RENAME_LOCKED_FILES = 1 solved the issue.
Is this workaround a permanent solution? what is the effect of this parameter?

@erinha

This comment has been minimized.

Show comment
Hide comment
@erinha

erinha Dec 7, 2016

Member

The VSTS Azure App Service Deploy task fails occasionally with ERROR_FILE_IN_USE when deploying to a deployment slot and unfortunately using MSDEPLOY_RENAME_LOCKED_FILES=1 did not solve the issue for me. Checking "Take App Offline" also doesn't prevent the failure. The only solution I've found so far that works is to have an Azure PowerShell task run before the deployment to stop the service slot and then restart it again after the deployment. This doesn't seem expected though, based on the previous comments.

Can someone please provide more clarity about what the MSDEPLOY_RENAME_LOCKED_FILES setting does, and how it should be used?

Member

erinha commented Dec 7, 2016

The VSTS Azure App Service Deploy task fails occasionally with ERROR_FILE_IN_USE when deploying to a deployment slot and unfortunately using MSDEPLOY_RENAME_LOCKED_FILES=1 did not solve the issue for me. Checking "Take App Offline" also doesn't prevent the failure. The only solution I've found so far that works is to have an Azure PowerShell task run before the deployment to stop the service slot and then restart it again after the deployment. This doesn't seem expected though, based on the previous comments.

Can someone please provide more clarity about what the MSDEPLOY_RENAME_LOCKED_FILES setting does, and how it should be used?

@rajatagrawal-dev

This comment has been minimized.

Show comment
Hide comment
@rajatagrawal-dev

rajatagrawal-dev Dec 9, 2016

Member

Hi @erinha

Can you provide us with the debug/verbose logs? We are in the process of forwarding this issue to the Azure team and your logs will help them in debugging it.
By setting MSDEPLOY_RENAME_LOCKED_FILES=1 in the Azure App Settings, WebDeploy will attempt to rename the DLL if it can’t be overwritten.
Azure team is better equipped to answer these questions in detail. So please send us the debug logs at RM_Customer_Queries at Microsoft dot com.

To get the debug logs please add a variable "system.debug" in your release definition and set its value to "true". Triggering a release then will give you the release logs.

Member

rajatagrawal-dev commented Dec 9, 2016

Hi @erinha

Can you provide us with the debug/verbose logs? We are in the process of forwarding this issue to the Azure team and your logs will help them in debugging it.
By setting MSDEPLOY_RENAME_LOCKED_FILES=1 in the Azure App Settings, WebDeploy will attempt to rename the DLL if it can’t be overwritten.
Azure team is better equipped to answer these questions in detail. So please send us the debug logs at RM_Customer_Queries at Microsoft dot com.

To get the debug logs please add a variable "system.debug" in your release definition and set its value to "true". Triggering a release then will give you the release logs.

@erinha

This comment has been minimized.

Show comment
Hide comment
@erinha

erinha Dec 9, 2016

Member

Sure, I can send logs.

There are a couple of problems though:

  1. The issue is intermittent (if I trigger the release deployment manually, it does not occur). I have to wait for a triggered deployment to occur (based on when someone on our team pushes to master).
  2. I've currently worked around the issue by adding an Azure PowerShell task to stop the service before deploying to the slot and another after the deployment to start the service. So with this in place I don't see the error.

I'm assuming that the debug logs are only useful when the error occurs, so I'll enable debug logs for the definition and then have to disable my workarounds and wait for a failure.

Member

erinha commented Dec 9, 2016

Sure, I can send logs.

There are a couple of problems though:

  1. The issue is intermittent (if I trigger the release deployment manually, it does not occur). I have to wait for a triggered deployment to occur (based on when someone on our team pushes to master).
  2. I've currently worked around the issue by adding an Azure PowerShell task to stop the service before deploying to the slot and another after the deployment to start the service. So with this in place I don't see the error.

I'm assuming that the debug logs are only useful when the error occurs, so I'll enable debug logs for the definition and then have to disable my workarounds and wait for a failure.

@erinha

This comment has been minimized.

Show comment
Hide comment
@erinha

erinha Dec 12, 2016

Member

FYI @rajatagrawal-dev, I was able to capture logs and sent them to the RM_Customer_Queries at Microsoft dot com email address, as you instructed. Hopefully they'll help diagnose the issue!

Member

erinha commented Dec 12, 2016

FYI @rajatagrawal-dev, I was able to capture logs and sent them to the RM_Customer_Queries at Microsoft dot com email address, as you instructed. Hopefully they'll help diagnose the issue!

@jdshkolnik

This comment has been minimized.

Show comment
Hide comment
@jdshkolnik

jdshkolnik Dec 20, 2016

This is also happening with TFS 2017.

jdshkolnik commented Dec 20, 2016

This is also happening with TFS 2017.

@onionhammer

This comment has been minimized.

Show comment
Hide comment
@onionhammer

onionhammer Dec 22, 2016

Yeah I'm using the new MS deploy task in release management VSTS, and I'm seeing this issue. I'm using the 'take app offline' flag and I'm using the MSDEPLOY_RENAME_LOCKED_FILES=1 setting.

This is the error I'm seeing. Could it be a byproduct of using the 'always online' setting for the web app? Also this is a aspnet core (on full .net framework) app.


2016-12-22T15:33:04.8639698Z Info: Using ID '755cb0bc-77e3-49eb-a055-b7342067560f' for connections to the remote server.
 
2016-12-22T15:33:06.7768978Z Info: Using ID 'a21a4759-da36-4412-ac68-fda97671b780' for connections to the remote server.
 
2016-12-22T15:33:11.2419112Z Info: Updating file (prod-c2c-borrowers\CRF.Connect2Capital.BorrowerWeb.exe).
 
2016-12-22T15:33:13.0488909Z ##[debug]rc:4294967295
 
2016-12-22T15:33:13.0488909Z ##[debug]rc:4294967295
 
2016-12-22T15:33:13.0488909Z ##[debug]success:false
 
2016-12-22T15:33:13.0488909Z ##[debug]success:false
 
2016-12-22T15:33:13.0608910Z ##[error]Failed to deploy website.
 
2016-12-22T15:33:13.0608910Z ##[debug]Processed: ##vso[task.issue type=error;]Failed to deploy website.
 
2016-12-22T15:33:13.0618962Z ##[debug]System.DefaultWorkingDirectory=C:\a\r1\a
 
2016-12-22T15:33:13.0618962Z ##[error]Error Code: ERROR_FILE_IN_USE
 
2016-12-22T15:33:13.0618962Z ##[debug]Processed: ##vso[task.issue type=error;]Error Code: ERROR_FILE_IN_USE
 
2016-12-22T15:33:13.0618962Z More Information: Web Deploy cannot modify the file 'CRF.Connect2Capital.BorrowerWeb.exe' 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.
 
2016-12-22T15:33:13.0618962Z Error count: 1.
 
2016-12-22T15:33:13.0618962Z 

onionhammer commented Dec 22, 2016

Yeah I'm using the new MS deploy task in release management VSTS, and I'm seeing this issue. I'm using the 'take app offline' flag and I'm using the MSDEPLOY_RENAME_LOCKED_FILES=1 setting.

This is the error I'm seeing. Could it be a byproduct of using the 'always online' setting for the web app? Also this is a aspnet core (on full .net framework) app.


2016-12-22T15:33:04.8639698Z Info: Using ID '755cb0bc-77e3-49eb-a055-b7342067560f' for connections to the remote server.
 
2016-12-22T15:33:06.7768978Z Info: Using ID 'a21a4759-da36-4412-ac68-fda97671b780' for connections to the remote server.
 
2016-12-22T15:33:11.2419112Z Info: Updating file (prod-c2c-borrowers\CRF.Connect2Capital.BorrowerWeb.exe).
 
2016-12-22T15:33:13.0488909Z ##[debug]rc:4294967295
 
2016-12-22T15:33:13.0488909Z ##[debug]rc:4294967295
 
2016-12-22T15:33:13.0488909Z ##[debug]success:false
 
2016-12-22T15:33:13.0488909Z ##[debug]success:false
 
2016-12-22T15:33:13.0608910Z ##[error]Failed to deploy website.
 
2016-12-22T15:33:13.0608910Z ##[debug]Processed: ##vso[task.issue type=error;]Failed to deploy website.
 
2016-12-22T15:33:13.0618962Z ##[debug]System.DefaultWorkingDirectory=C:\a\r1\a
 
2016-12-22T15:33:13.0618962Z ##[error]Error Code: ERROR_FILE_IN_USE
 
2016-12-22T15:33:13.0618962Z ##[debug]Processed: ##vso[task.issue type=error;]Error Code: ERROR_FILE_IN_USE
 
2016-12-22T15:33:13.0618962Z More Information: Web Deploy cannot modify the file 'CRF.Connect2Capital.BorrowerWeb.exe' 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.
 
2016-12-22T15:33:13.0618962Z Error count: 1.
 
2016-12-22T15:33:13.0618962Z 
@OnTheMike

This comment has been minimized.

Show comment
Hide comment
@OnTheMike

OnTheMike Aug 8, 2017

We are deploying via Jenkins, calling msdeploy directly. So it seems to be Azure-related. I've just tried the option with the extended interval and retry, that seems to work. Haven't tried it with autoswap yet.

OnTheMike commented Aug 8, 2017

We are deploying via Jenkins, calling msdeploy directly. So it seems to be Azure-related. I've just tried the option with the extended interval and retry, that seems to work. Haven't tried it with autoswap yet.

@OnTheMike

This comment has been minimized.

Show comment
Hide comment
@OnTheMike

OnTheMike Aug 8, 2017

Seems to work fine with autoswap as well.

OnTheMike commented Aug 8, 2017

Seems to work fine with autoswap as well.

@jim-strang

This comment has been minimized.

Show comment
Hide comment
@jim-strang

jim-strang Aug 8, 2017

The msdeploy retry attempts and retry interval flags seemed to have solved the problem for me as well. I also went a step further and used some powershell scripts to deploy and remove a custom app_offline.htm to the wwwroot folder before and after my VSTS deployment task using the Kudu API. This is a good resource if you want to go down that route too.

jim-strang commented Aug 8, 2017

The msdeploy retry attempts and retry interval flags seemed to have solved the problem for me as well. I also went a step further and used some powershell scripts to deploy and remove a custom app_offline.htm to the wwwroot folder before and after my VSTS deployment task using the Kudu API. This is a good resource if you want to go down that route too.

@davidebbo

This comment has been minimized.

Show comment
Hide comment
@davidebbo

davidebbo Aug 8, 2017

FYI, I documented the issue and workaround on Azure/app-service-announcements#24.

Note that I suggest only tweaking retry attempts and leave the interval at the default 1 second. Increasing the interval can slow down your deployment more than necessary, and there is nothing wrong with trying every second.

Let me know if you have any feedback/clarifications on the announcement.

davidebbo commented Aug 8, 2017

FYI, I documented the issue and workaround on Azure/app-service-announcements#24.

Note that I suggest only tweaking retry attempts and leave the interval at the default 1 second. Increasing the interval can slow down your deployment more than necessary, and there is nothing wrong with trying every second.

Let me know if you have any feedback/clarifications on the announcement.

@AaronRM

This comment has been minimized.

Show comment
Hide comment
@AaronRM

AaronRM Aug 8, 2017

Member

@davidebbo Even when setting -retryAttempts:80, we're still consistently hitting ERROR_FILE_IN_USE. We also have 'Take App Offline' and 'Rename locked files' checked. Should we just continue trying to increase the retryAttempts value until we hit a threshold where it consistently succeeds?

Member

AaronRM commented Aug 8, 2017

@davidebbo Even when setting -retryAttempts:80, we're still consistently hitting ERROR_FILE_IN_USE. We also have 'Take App Offline' and 'Rename locked files' checked. Should we just continue trying to increase the retryAttempts value until we hit a threshold where it consistently succeeds?

@davidebbo

This comment has been minimized.

Show comment
Hide comment
@davidebbo

davidebbo Aug 8, 2017

@AArnott you may have an unrelated issue. What specific file is in use? Try manually creating app_offline.html in Kudu console, and check whether the dotnet process eventually shuts down (you can check via Kudu Process Explorer).

davidebbo commented Aug 8, 2017

@AArnott you may have an unrelated issue. What specific file is in use? Try manually creating app_offline.html in Kudu console, and check whether the dotnet process eventually shuts down (you can check via Kudu Process Explorer).

@AaronRM

This comment has been minimized.

Show comment
Hide comment
@AaronRM

AaronRM Aug 8, 2017

Member

@davidebbo I presume you meant me. :) Indeed, there was some other issue going on with the particular app in question (was in a strange state where the app exe wasn't running). The file in use error we were seeing was the app executable itself. Stopping the app and re-deploying appears to have fixed it. Thanks!

Member

AaronRM commented Aug 8, 2017

@davidebbo I presume you meant me. :) Indeed, there was some other issue going on with the particular app in question (was in a strange state where the app exe wasn't running). The file in use error we were seeing was the app executable itself. Stopping the app and re-deploying appears to have fixed it. Thanks!

@davidebbo

This comment has been minimized.

Show comment
Hide comment
@davidebbo

davidebbo Aug 8, 2017

@AaronRM yep, sorry, GitHub name completion fail on my part :)

Glad you figured it out.

davidebbo commented Aug 8, 2017

@AaronRM yep, sorry, GitHub name completion fail on my part :)

Glad you figured it out.

@AaronRM

This comment has been minimized.

Show comment
Hide comment
@AaronRM

AaronRM Aug 9, 2017

Member

@davidebbo I retract my previous comment. We are still hitting this regularly across several different apps/environments. FWIW, this is an ASP .NET Core app running on Full .NET Framework. When it does fail, it's the app executable that's the file in use:

2017-08-09T19:26:14.3813460Z` ##[error]Failed to deploy web package to App Service.
2017-08-09T19:26:14.3813460Z ##[warning]Try to deploy app service again with Rename locked files option selected.
2017-08-09T19:26:14.3813460Z ##[error]Error Code: ERROR_FILE_IN_USE
More Information: Web Deploy cannot modify the file 'App.exe' 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-08-09T19:26:14.3823659Z ##[error]Error: C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe failed with return code: 4294967295
Member

AaronRM commented Aug 9, 2017

@davidebbo I retract my previous comment. We are still hitting this regularly across several different apps/environments. FWIW, this is an ASP .NET Core app running on Full .NET Framework. When it does fail, it's the app executable that's the file in use:

2017-08-09T19:26:14.3813460Z` ##[error]Failed to deploy web package to App Service.
2017-08-09T19:26:14.3813460Z ##[warning]Try to deploy app service again with Rename locked files option selected.
2017-08-09T19:26:14.3813460Z ##[error]Error Code: ERROR_FILE_IN_USE
More Information: Web Deploy cannot modify the file 'App.exe' 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-08-09T19:26:14.3823659Z ##[error]Error: C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe failed with return code: 4294967295
@mehalick

This comment has been minimized.

Show comment
Hide comment
@mehalick

mehalick Aug 9, 2017

Same issue for me very consistently, also using ASP.NET Core running on full .NET framework.

2017-08-09T21:41:30.0475840Z Info: Updating file (bilbayt-api\Bilbayt.Api.exe).
2017-08-09T21:41:33.7547205Z ##[error]Failed to deploy web package to App Service.
2017-08-09T21:41:33.7557130Z ##[warning]Try to deploy app service again with Rename locked files option selected.
2017-08-09T21:41:33.7557130Z ##[error]Error Code: ERROR_FILE_IN_USE
More Information: Web Deploy cannot modify the file 'Bilbayt.Api.exe' 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've tried all workarounds above with no success. I can confirm that the VSTS Azure Publish task writes App_Offline.html and not app_offline.html if that makes a difference.

mehalick commented Aug 9, 2017

Same issue for me very consistently, also using ASP.NET Core running on full .NET framework.

2017-08-09T21:41:30.0475840Z Info: Updating file (bilbayt-api\Bilbayt.Api.exe).
2017-08-09T21:41:33.7547205Z ##[error]Failed to deploy web package to App Service.
2017-08-09T21:41:33.7557130Z ##[warning]Try to deploy app service again with Rename locked files option selected.
2017-08-09T21:41:33.7557130Z ##[error]Error Code: ERROR_FILE_IN_USE
More Information: Web Deploy cannot modify the file 'Bilbayt.Api.exe' 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've tried all workarounds above with no success. I can confirm that the VSTS Azure Publish task writes App_Offline.html and not app_offline.html if that makes a difference.

@davidebbo

This comment has been minimized.

Show comment
Hide comment
@davidebbo

davidebbo Aug 9, 2017

@mehalick did you try manually creating app_offline.htm from Kudu console to see if that triggers the eventual process shutdown? That is a good way to help isolate.

davidebbo commented Aug 9, 2017

@mehalick did you try manually creating app_offline.htm from Kudu console to see if that triggers the eventual process shutdown? That is a good way to help isolate.

@pan-wang

This comment has been minimized.

Show comment
Hide comment
@pan-wang

pan-wang Aug 10, 2017

@AaronRM @mehalick Once ANCM module detects the creation of app_offline.htm (case insensitive), it will try to gracefully shutdown the backend process (default timeout 10s). If failed, ANCM will kill the backend and log a warning to Windows event log. Could you please enable collecting windows event log on Portal during deployment and share the log?

pan-wang commented Aug 10, 2017

@AaronRM @mehalick Once ANCM module detects the creation of app_offline.htm (case insensitive), it will try to gracefully shutdown the backend process (default timeout 10s). If failed, ANCM will kill the backend and log a warning to Windows event log. Could you please enable collecting windows event log on Portal during deployment and share the log?

@AaronRM

This comment has been minimized.

Show comment
Hide comment
@AaronRM

AaronRM Aug 10, 2017

Member

@pan-wang Where is the setting in the Azure Portal to enable collecting the Windows Event Log during deployments?

Member

AaronRM commented Aug 10, 2017

@pan-wang Where is the setting in the Azure Portal to enable collecting the Windows Event Log during deployments?

@thuru

This comment has been minimized.

Show comment
Hide comment
@thuru

thuru Aug 11, 2017

@AaronRM : yes I experience the same, and the builds one after the other gets succeeded, this pattern is a very consistent from last week.

2/2 occurring from Aug 3rd. When queued again it goes success. Every build one after the other getting success. @VSTS pic.twitter.com/QVIunduzxw

— Thuru (@ThuruTweets) August 4, 2017
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

thuru commented Aug 11, 2017

@AaronRM : yes I experience the same, and the builds one after the other gets succeeded, this pattern is a very consistent from last week.

2/2 occurring from Aug 3rd. When queued again it goes success. Every build one after the other getting success. @VSTS pic.twitter.com/QVIunduzxw

— Thuru (@ThuruTweets) August 4, 2017
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
@mehalick

This comment has been minimized.

Show comment
Hide comment
@mehalick

mehalick Aug 11, 2017

I can consistently reproduce the issue in Kudu with an ASP.NET Core 1.1 site running on the full framework (Net47). When creating App_Offline.htm manually in Kudu I log the shutdown process starting but failing with a 404:

Sent shutdown HTTP message to process '8468' and received http status '404'.

Within a few seconds I log a second message:

Failed to gracefully shutdown process '8468'.

Here's the full eventlog.xml from Kudu:

<Events>
    <Event>
        <System>
            <Provider Name="IIS AspNetCore Module"/>
            <EventID>1001</EventID>
            <Level>0</Level>
            <Task>0</Task>
            <Keywords>Keywords</Keywords>
            <TimeCreated SystemTime="2017-08-11T12:49:45Z"/>
            <EventRecordID>563262140</EventRecordID>
            <Channel>Application</Channel>
            <Computer>RD0003FF70DE37</Computer>
            <Security/>
        </System>
        <EventData>
            <Data>Application 'MACHINE/WEBROOT/APPHOST/BILBAYT-API' started process '8468' successfully and is listening on port '33198'.</Data>
        </EventData>
    </Event>
    <Event>
        <System>
            <Provider Name="IIS AspNetCore Module"/>
            <EventID>1006</EventID>
            <Level>0</Level>
            <Task>0</Task>
            <Keywords>Keywords</Keywords>
            <TimeCreated SystemTime="2017-08-11T12:50:35Z"/>
            <EventRecordID>563312156</EventRecordID>
            <Channel>Application</Channel>
            <Computer>RD0003FF70DE37</Computer>
            <Security/>
        </System>
        <EventData>
            <Data>Sent shutdown HTTP message to process '8468' and received http status '404'.</Data>
        </EventData>
    </Event>
    <Event>
        <System>
            <Provider Name="IIS AspNetCore Module"/>
            <EventID>1005</EventID>
            <Level>0</Level>
            <Task>0</Task>
            <Keywords>Keywords</Keywords>
            <TimeCreated SystemTime="2017-08-11T12:50:45Z"/>
            <EventRecordID>563321984</EventRecordID>
            <Channel>Application</Channel>
            <Computer>RD0003FF70DE37</Computer>
            <Security/>
        </System>
        <EventData>
            <Data>Failed to gracefully shutdown process '8468'.</Data>
        </EventData>
    </Event>
</Events>

Here's a 35 second screen capture of the process that consistently generates the error for me:

https://andy.azureedge.net/blog/2017-08-11_8-50-58.mp4

mehalick commented Aug 11, 2017

I can consistently reproduce the issue in Kudu with an ASP.NET Core 1.1 site running on the full framework (Net47). When creating App_Offline.htm manually in Kudu I log the shutdown process starting but failing with a 404:

Sent shutdown HTTP message to process '8468' and received http status '404'.

Within a few seconds I log a second message:

Failed to gracefully shutdown process '8468'.

Here's the full eventlog.xml from Kudu:

<Events>
    <Event>
        <System>
            <Provider Name="IIS AspNetCore Module"/>
            <EventID>1001</EventID>
            <Level>0</Level>
            <Task>0</Task>
            <Keywords>Keywords</Keywords>
            <TimeCreated SystemTime="2017-08-11T12:49:45Z"/>
            <EventRecordID>563262140</EventRecordID>
            <Channel>Application</Channel>
            <Computer>RD0003FF70DE37</Computer>
            <Security/>
        </System>
        <EventData>
            <Data>Application 'MACHINE/WEBROOT/APPHOST/BILBAYT-API' started process '8468' successfully and is listening on port '33198'.</Data>
        </EventData>
    </Event>
    <Event>
        <System>
            <Provider Name="IIS AspNetCore Module"/>
            <EventID>1006</EventID>
            <Level>0</Level>
            <Task>0</Task>
            <Keywords>Keywords</Keywords>
            <TimeCreated SystemTime="2017-08-11T12:50:35Z"/>
            <EventRecordID>563312156</EventRecordID>
            <Channel>Application</Channel>
            <Computer>RD0003FF70DE37</Computer>
            <Security/>
        </System>
        <EventData>
            <Data>Sent shutdown HTTP message to process '8468' and received http status '404'.</Data>
        </EventData>
    </Event>
    <Event>
        <System>
            <Provider Name="IIS AspNetCore Module"/>
            <EventID>1005</EventID>
            <Level>0</Level>
            <Task>0</Task>
            <Keywords>Keywords</Keywords>
            <TimeCreated SystemTime="2017-08-11T12:50:45Z"/>
            <EventRecordID>563321984</EventRecordID>
            <Channel>Application</Channel>
            <Computer>RD0003FF70DE37</Computer>
            <Security/>
        </System>
        <EventData>
            <Data>Failed to gracefully shutdown process '8468'.</Data>
        </EventData>
    </Event>
</Events>

Here's a 35 second screen capture of the process that consistently generates the error for me:

https://andy.azureedge.net/blog/2017-08-11_8-50-58.mp4

@pan-wang

This comment has been minimized.

Show comment
Hide comment
@pan-wang

pan-wang Aug 11, 2017

@mehalick This is a regression in ANCM (build 1983) which added graceful shutdown support allowing the application to finish long running request in given time. The change somehow ignored some failure path. As result, ANCM will wait for timeout (default 10 seconds) in some code path instead of aggressively terminating the backend process. This regression has been fixed in new ANCM (build 1984) which is till under deployment.

After the graceful shutdown failure event, the backend process should have been killed and you should be able to deploy the new assemblies. If this not the case, please let me know.

Please do add retry mechanism in your deployment as posted by David even after the regression has been fixed. This is because due to graceful shutdown, the application is given more time (configurable) to finish requests and exit. A long running request may hold the backend process till timeout.

pan-wang commented Aug 11, 2017

@mehalick This is a regression in ANCM (build 1983) which added graceful shutdown support allowing the application to finish long running request in given time. The change somehow ignored some failure path. As result, ANCM will wait for timeout (default 10 seconds) in some code path instead of aggressively terminating the backend process. This regression has been fixed in new ANCM (build 1984) which is till under deployment.

After the graceful shutdown failure event, the backend process should have been killed and you should be able to deploy the new assemblies. If this not the case, please let me know.

Please do add retry mechanism in your deployment as posted by David even after the regression has been fixed. This is because due to graceful shutdown, the application is given more time (configurable) to finish requests and exit. A long running request may hold the backend process till timeout.

@hkusulja

This comment has been minimized.

Show comment
Hide comment
@hkusulja

hkusulja Aug 11, 2017

@pan-wang any expected date when this is expected to be fixed on Azure production? Thank you

hkusulja commented Aug 11, 2017

@pan-wang any expected date when this is expected to be fixed on Azure production? Thank you

@mehalick

This comment has been minimized.

Show comment
Hide comment
@mehalick

mehalick Aug 11, 2017

@pan-wang I can confirm that adding a retry to my deployment is a successful workaround, thank you.

For the record I'm deploying via VSTS, while there's not exactly a retry option this can be achieved by duplicating the deployment task but set to run only on failure of a previous task. This isn't a great long-term solution but it's acceptable for now.

mehalick commented Aug 11, 2017

@pan-wang I can confirm that adding a retry to my deployment is a successful workaround, thank you.

For the record I'm deploying via VSTS, while there's not exactly a retry option this can be achieved by duplicating the deployment task but set to run only on failure of a previous task. This isn't a great long-term solution but it's acceptable for now.

@davidebbo

This comment has been minimized.

Show comment
Hide comment
@davidebbo

davidebbo Aug 11, 2017

@hkusulja the fix should be deployed by the end of the month.

davidebbo commented Aug 11, 2017

@hkusulja the fix should be deployed by the end of the month.

@matthieugd

This comment has been minimized.

Show comment
Hide comment
@matthieugd

matthieugd Aug 14, 2017

We are using a Powershell script to publish our app. We tried to set the retryAttemps but it doesn't fix the problem. It seems that the retryAttemps value is not correctly handled?

Log:

[Step 1/4] PowerShell Executable: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe [10:26:21][Step 1/4] Working directory: C:\Data\teamcity\server\buildAgent\work\392f4ac975965f5\scripts_backend [10:26:21][Step 1/4] Command: C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe [10:26:21][Step 1/4] PowerShell arguments: -Version, 5.0, -NonInteractive, -ExecutionPolicy, ByPass, -File, C:\Data\teamcity\server\buildAgent\work\392f4ac975965f5\scripts_backend\publish-backend.ps1, -slot, dev [10:26:22][Step 1/4] Path: C:\Data\teamcity\server\buildAgent\work\392f4ac975965f5\scripts_backend\publish.ps1 [10:26:23][Step 1/4] VERBOSE: Loading module from path [10:26:23][Step 1/4] 'C:\Data\teamcity\server\buildAgent\work\392f4ac975965f5\scripts_backend\publis [10:26:23][Step 1/4] h-module.psm1'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Get-AspnetPublishHandler'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Get-MSDeploy'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Get-PropertiesFromPublishProfile'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Publish-AspNet'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Publish-AspNetFileSystem'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Publish-AspNetMSDeploy'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Publish-AspNetMSDeployPackage'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Register-AspnetPublishHandler'. [10:26:23][Step 1/4] Publishing with publish method [MSDeploy] [10:26:23][Step 1/4] Executing command ["C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:manifest='C:\Data\teamcity\server\buildAgent\temp\buildTmp\PublishTemp\obj\publish_backend\SourceManifest.xml' -dest:manifest='C:\Data\teamcity\server\buildAgent\temp\buildTmp\PublishTemp\obj\publish_backend\DestinationManifest.xml',ComputerName='https://XXXX.scm.azurewebsites.net/msdeploy.axd?site=XXXX-backend__dev',UserName='$XXXX-backend__dev', Password='{PASSWORD-REMOVED-FROM-LOG}',IncludeAcls='False',AuthType='Basic' -verb:sync -enablerule:AppOffline -enableRule:DoNotDeleteRule -retryAttempts:20 -disablerule:BackupRule] [10:26:52][Step 1/4] Info: Using ID '9baa4f23-3dbe-49e4-93c2-286f08be116c' for connections to the remote server. [10:26:52][Step 1/4] Info: Using ID '0b6871d3-5e6b-48ee-9e79-380490592301' for connections to the remote server. [10:26:52][Step 1/4] Info: Updating file (XXXX-backend__dev\AngleSharp.dll). [10:26:52][Step 1/4] Info: Updating file (XXXX-backend__dev\Apcurium.Boost.dll). [10:26:52][Step 1/4] [10:26:52][Step 1/4] Error Code: ERROR_FILE_IN_USEMore Information: Web Deploy cannot modify the file 'XXXX.Boost.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.

matthieugd commented Aug 14, 2017

We are using a Powershell script to publish our app. We tried to set the retryAttemps but it doesn't fix the problem. It seems that the retryAttemps value is not correctly handled?

Log:

[Step 1/4] PowerShell Executable: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe [10:26:21][Step 1/4] Working directory: C:\Data\teamcity\server\buildAgent\work\392f4ac975965f5\scripts_backend [10:26:21][Step 1/4] Command: C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe [10:26:21][Step 1/4] PowerShell arguments: -Version, 5.0, -NonInteractive, -ExecutionPolicy, ByPass, -File, C:\Data\teamcity\server\buildAgent\work\392f4ac975965f5\scripts_backend\publish-backend.ps1, -slot, dev [10:26:22][Step 1/4] Path: C:\Data\teamcity\server\buildAgent\work\392f4ac975965f5\scripts_backend\publish.ps1 [10:26:23][Step 1/4] VERBOSE: Loading module from path [10:26:23][Step 1/4] 'C:\Data\teamcity\server\buildAgent\work\392f4ac975965f5\scripts_backend\publis [10:26:23][Step 1/4] h-module.psm1'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Get-AspnetPublishHandler'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Get-MSDeploy'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Get-PropertiesFromPublishProfile'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Publish-AspNet'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Publish-AspNetFileSystem'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Publish-AspNetMSDeploy'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Publish-AspNetMSDeployPackage'. [10:26:23][Step 1/4] VERBOSE: Importing function 'Register-AspnetPublishHandler'. [10:26:23][Step 1/4] Publishing with publish method [MSDeploy] [10:26:23][Step 1/4] Executing command ["C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:manifest='C:\Data\teamcity\server\buildAgent\temp\buildTmp\PublishTemp\obj\publish_backend\SourceManifest.xml' -dest:manifest='C:\Data\teamcity\server\buildAgent\temp\buildTmp\PublishTemp\obj\publish_backend\DestinationManifest.xml',ComputerName='https://XXXX.scm.azurewebsites.net/msdeploy.axd?site=XXXX-backend__dev',UserName='$XXXX-backend__dev', Password='{PASSWORD-REMOVED-FROM-LOG}',IncludeAcls='False',AuthType='Basic' -verb:sync -enablerule:AppOffline -enableRule:DoNotDeleteRule -retryAttempts:20 -disablerule:BackupRule] [10:26:52][Step 1/4] Info: Using ID '9baa4f23-3dbe-49e4-93c2-286f08be116c' for connections to the remote server. [10:26:52][Step 1/4] Info: Using ID '0b6871d3-5e6b-48ee-9e79-380490592301' for connections to the remote server. [10:26:52][Step 1/4] Info: Updating file (XXXX-backend__dev\AngleSharp.dll). [10:26:52][Step 1/4] Info: Updating file (XXXX-backend__dev\Apcurium.Boost.dll). [10:26:52][Step 1/4] [10:26:52][Step 1/4] Error Code: ERROR_FILE_IN_USEMore Information: Web Deploy cannot modify the file 'XXXX.Boost.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.

@IvanAlekseev

This comment has been minimized.

Show comment
Hide comment
@IvanAlekseev

IvanAlekseev Sep 7, 2017

@davidebbo what is a current state of this issue? It is really annoying

IvanAlekseev commented Sep 7, 2017

@davidebbo what is a current state of this issue? It is really annoying

@davidebbo

This comment has been minimized.

Show comment
Hide comment
@davidebbo

davidebbo Sep 7, 2017

@IvanAlekseev The fixed ANCM @pan-wang's refers to is fully deployed. So if you are still running into issues, it is likely something different, and it may be best to open a new issue.

davidebbo commented Sep 7, 2017

@IvanAlekseev The fixed ANCM @pan-wang's refers to is fully deployed. So if you are still running into issues, it is likely something different, and it may be best to open a new issue.

@CanisLupus

This comment has been minimized.

Show comment
Hide comment
@CanisLupus

CanisLupus Sep 13, 2017

Is this really fixed? I have VS updated as per the Visual Studio Installer, I have MSDEPLOY_RENAME_LOCKED_FILES set to 1 on the server, I have added <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> to the .pubxml file and most of the time I get a "Publishing failed" message. After it appears, restarting the server doesn't help. The only way I can publish at that time is delete every file in the server and then reupload everything. Am I missing something? I'm trying to upload an ASP.NET Core application to Azure (with WebDeploy).

CanisLupus commented Sep 13, 2017

Is this really fixed? I have VS updated as per the Visual Studio Installer, I have MSDEPLOY_RENAME_LOCKED_FILES set to 1 on the server, I have added <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> to the .pubxml file and most of the time I get a "Publishing failed" message. After it appears, restarting the server doesn't help. The only way I can publish at that time is delete every file in the server and then reupload everything. Am I missing something? I'm trying to upload an ASP.NET Core application to Azure (with WebDeploy).

@rmarinho

This comment has been minimized.

Show comment
Hide comment
@rmarinho

rmarinho Sep 13, 2017

Member

Hey @vincentdass discuss moving from #4365

Nop i didn't put the app offline, I will try. I m not using webjobs but i m using ApplicationInsights.

Member

rmarinho commented Sep 13, 2017

Hey @vincentdass discuss moving from #4365

Nop i didn't put the app offline, I will try. I m not using webjobs but i m using ApplicationInsights.

@kmkumaran kmkumaran assigned vincentdass and unassigned chshrikh Sep 14, 2017

@henkmollema

This comment has been minimized.

Show comment
Hide comment
@henkmollema

henkmollema Sep 15, 2017

How can this be closed? We still hit this issue daily with our ASP.NET Core apps and it's really killing a productive CI workflow.

henkmollema commented Sep 15, 2017

How can this be closed? We still hit this issue daily with our ASP.NET Core apps and it's really killing a productive CI workflow.

@vincentdass

This comment has been minimized.

Show comment
Hide comment
@vincentdass

vincentdass Sep 16, 2017

Member

@henkmollema , apologies for the inconvenienvce.
We have an active thread here to follow on this issue.

Member

vincentdass commented Sep 16, 2017

@henkmollema , apologies for the inconvenienvce.
We have an active thread here to follow on this issue.

@henkmollema

This comment has been minimized.

Show comment
Hide comment
@henkmollema

henkmollema Sep 18, 2017

@vincentdass thanks, I'll keep an eye on it.

henkmollema commented Sep 18, 2017

@vincentdass thanks, I'll keep an eye on it.

@danieldiazastudillo

This comment has been minimized.

Show comment
Hide comment
@danieldiazastudillo

danieldiazastudillo Oct 7, 2017

My first Core app, candidate to go on production and this error comes up, from nothing, out of nowhere :(. No update, no changes, nothing. I had to stop the app on Azure, publish via VS and it worked. I'll configure CI/CD with GitHub and see what happens, i've never had this problem before (.NET Classic and so on)

danieldiazastudillo commented Oct 7, 2017

My first Core app, candidate to go on production and this error comes up, from nothing, out of nowhere :(. No update, no changes, nothing. I had to stop the app on Azure, publish via VS and it worked. I'll configure CI/CD with GitHub and see what happens, i've never had this problem before (.NET Classic and so on)

@diegohb

This comment has been minimized.

Show comment
Hide comment
@diegohb

diegohb Nov 1, 2017

In teamcity, only way I could get it to work was to stop and start the app/slot.. i use an auto-swap slot named "production-alternate" and only deploy to it.. which I think means either that slot or production instance will always be up.. i also have build config using retry trigger.. in addition to sleeping after stopping site cause I was getting errors sporadically... i used azure-cli.

here's a teamcity metarunner i created: https://gist.github.com/diegohb/1e32fa0728110024c904de6c7ac5130b

diegohb commented Nov 1, 2017

In teamcity, only way I could get it to work was to stop and start the app/slot.. i use an auto-swap slot named "production-alternate" and only deploy to it.. which I think means either that slot or production instance will always be up.. i also have build config using retry trigger.. in addition to sleeping after stopping site cause I was getting errors sporadically... i used azure-cli.

here's a teamcity metarunner i created: https://gist.github.com/diegohb/1e32fa0728110024c904de6c7ac5130b

@Ro3A

This comment has been minimized.

Show comment
Hide comment
@Ro3A

Ro3A Nov 29, 2017

I've landed here from aspnet/Home#694 and Azure/app-service-announcements#24.

I'm still seeing an issue with locked files during deployment from Visual Studio 2017. I've been using MSDEPLOY_RENAME_LOCKED_FILES for two years now with a staging slot with no issues. All of a sudden, I'm guessing after a VS 2017 update, I'm unable to deploy to my staging slot.

Adding 20 into the csproj fixed the issue but the comments on the azure announcement indicate the issue has been resolved and thus the RetryAttempts workaround should not be necessary.

That is not the case, I've just tried it and it still fails without it.

Ro3A commented Nov 29, 2017

I've landed here from aspnet/Home#694 and Azure/app-service-announcements#24.

I'm still seeing an issue with locked files during deployment from Visual Studio 2017. I've been using MSDEPLOY_RENAME_LOCKED_FILES for two years now with a staging slot with no issues. All of a sudden, I'm guessing after a VS 2017 update, I'm unable to deploy to my staging slot.

Adding 20 into the csproj fixed the issue but the comments on the azure announcement indicate the issue has been resolved and thus the RetryAttempts workaround should not be necessary.

That is not the case, I've just tried it and it still fails without it.

@buzallen

This comment has been minimized.

Show comment
Hide comment
@buzallen

buzallen Dec 4, 2017

This is still an issue for me, but only on certain projects and I can't find a common thread as of this point. This is a .net core 2.0 MVC application being published to a azure web app. Only way around it is to stop the service and then restart it. Note this is not a slot in this case, it's the regular app.

Over the summer this was an issue on some other projects but that went away and I assumed the problem was fixed. In two new projects this issue is back. I have the retry attempts set at 20 but per another issue thread that is not needed anymore.

buzallen commented Dec 4, 2017

This is still an issue for me, but only on certain projects and I can't find a common thread as of this point. This is a .net core 2.0 MVC application being published to a azure web app. Only way around it is to stop the service and then restart it. Note this is not a slot in this case, it's the regular app.

Over the summer this was an issue on some other projects but that went away and I assumed the problem was fixed. In two new projects this issue is back. I have the retry attempts set at 20 but per another issue thread that is not needed anymore.

@yaananth

This comment has been minimized.

Show comment
Hide comment
@yaananth

yaananth Dec 5, 2017

Member

Please move discussions to #5259 to make sure it gets traction.

Member

yaananth commented Dec 5, 2017

Please move discussions to #5259 to make sure it gets traction.

@Microsoft Microsoft locked and limited conversation to collaborators Dec 5, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.