Azure-pipelines-tasks: AzureRmWebAppDeployment\2.1.6 fails to stop site so dll handles are not released, causing release to fail

[JoeBrockhaus]

publishing a dotnet core app which, in this case, is referencing IdentityModel.dll (where it fails), and some other non-core assemblies.

We've been able to get the deployment to work from VS if we stop the slot first.

4_Deploy AzureRM App Service ....zip

[chshrikh]

@JoeBrockhaus thanks for reporting the error. We are analyzing it. Is is happening consistently or intermediate one ?

[vincent1173]

@JoeBrockhaus , is the issue resolved ?

[JoeBrockhaus]

sorry for the delayed response guys. 

Initially it was happening consistently.

~As of this morning, using the 2.1.8 version, it looks like things are working as expected.~

jk, it's back - still broken.

[vincent1173]

@JoeBrockhaus, thanks for the response.

FILE_IN_USE issue occurs when DLL’s are locked. App_offline is believed to bring the app service down and unlock the resource. But the latest ASP.NET Core module expects app_offline.htm in root folder, but MSDeploy provides App_Offline.htm( case-sensitive). This issue is already in an active github issue with ASP.net repo and they informed that it will be fixed soon.

You can stop the App Service, Deploy the app and then start the app service to avoid FILE_IN_USE issue.

Please refer to this thread to manage app service via Build/Release.

[JoeBrockhaus]

@vincentdass ideally we would prefer a zero-downtime deployment. ie: uncheck the 'take app offline' box on the VSTS task.

Is that expected to be supported?

[vincent1173]

@JoeBrockhaus , For zero downtime deployment, You can deploy to a staging slot and then swap with production.
You can use Azure App Service Manage Task for Managing Azure App Service.
If dll's are locked in slots, then you need to Stop-Deploy-Start the slot.

[vincent1173]

@JoeBrockhaus , Can you please explain what will be the issue with swap slots ?

[JoeBrockhaus]

We've moved away from slot swaps for a few reasons.

It's unclear if the dll locking is an issue with the platform, the specific dll, the deployment task, etc, and it is easy for the buck to keep getting passed around as a result. Especially since this never happened before, the natural question is what changed that suddenly now it's not possible, and will things change again that would prevent us from needing to take these steps? 

Doing some quick rabbit-hole tracking, I can see many others have posted questions with these same issues and I'm not the only one who finds the run-around and fix-it-for-now solutions frustrating. I understand you guys are probably in the same boat - you are simply working with what you're able to as part of the platform.

Does this open issue you refer to change the eventual need to stop/start and/or swap slots? https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment-272804191

I also see mention of an app setting potentially solving the problem, and also that this should be done automatically during the deployment, but it too feels like a temporary hack, at best. MSDEPLOY_RENAME_LOCKED_FILES = 1

[vincent1173]

@JoeBrockhaus , thanks for your feedback.
We already added 'rename locked files' feature in 3.0-preview version of the task.

This task is available in most of the regions and will be available to all the regions in a week or two.

[mvvsubbu]

Closing this as there is another issue tracking the same, we will communicate on that issue once it is resolved by Azure Team https://github.com/Microsoft/vsts-tasks/issues/3312