Can't deploy to Elastic Beanstalk: ERROR_FILE_IN_USE

Question

My Elastic Beanstalk installation won't deploy through Visual Studio due to this error:

2016-07-01 20:45:02,627 ERROR 1 AWSBeanstalkCfnDeploy.DeploymentUtils - Exception during deployment. Microsoft.Web.Deployment.DeploymentDetailedClientServerException: Web Deploy cannot modify the file 'msvcr100.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.

The link suggests that I create a pubxml file with settings to enable AppOffline, but this file only seems to be relevant for publishing through VS using the built-in Publish feature. I haven't found any documentation suggesting that this will work for AWS.

How do I enable AppOffline for an Elastic Beanstalk deployment?

Thanks!

Answer 1

Sorry that this is only general advice and not the code you need, but the solution is to use hooks via .ebextensions. Please see http://docs.aws.amazon.com/codedeploy/latest/userguide/app-spec-ref-hooks.html.

You can add the execution of a powershell script to add app_offline.htm before the update is extracted and remove it once the update is deployed.

We had a similar issue, but the DLL in question (abcPDF, v9) was only blocked because we were initializing the licensing of it during application_start(), which EB did not like. So we moved applying the license elsewhere.

However, I think this approach would work.

-- Oh, maybe this container command will work for you. It recycles the IIS app pool right before the It didn't for us because of the aforementioned licensing locking the DLL.

/.ebextensions/recycleapppool.config

container_commands:

__recycle_app_pool:

____command: c:\windows\system32\inetsrv\appcmd.exe recycle apppool DefaultAppPool

Answer 2

After quite a lot of experimentation, the only working solution I could find for this problem was

// in Project/.ebextensions/reset.config

container_commands:
  00_nuke:
    command: IISReset
    waitAfterCompletion: 0

The cost was about 4 seconds of downtime (on a t2.micro), during which you get a 503, which certainly isn't great.

Note there's a Github issue for this (open at the time of writing).

If you have the option, deploy your service to Azure rather than AWS and there are configuration options to work around the issue (such as an environment variable MSDEPLOY_RENAME_LOCKED_FILES) - related Azure specific question.