Visual Studio Online / Azure stopping and starting web applications using Powershell

Question

I'm using Visual Studio Online's build tools to deploy web applications from a single solution. I've occasionally been running into file locking issues.

Error: Web Deploy cannot modify the file 'Microsoft.CodeAnalysis.CSharp.dll' on the destination because it is locked by an external process.

After some Googling, I believe the "fix" is to stop the web applications before deployment on Azure and start it back up after. Sounds legit.

However, there does not seem to be a straight forward way to do this directly on VSO's build definitions. I've created an "Azure Powershell" build task, but it wants a PS1 file from the repository. It doesn't seem to let me just run Azure Powershell commands (e.g. Stop-AzureWebsite) from here. My team has created a work-around where we have a "run.ps1" that just executes the command you pass as a parameter, but none of us are satisfied by that.

What are we missing? There has got to be an easier way to do this without having a PS1 script checked into source control.

Answer 1

I solved this by installing Azure App Services - Start and Stop extension from Visual Studio Marketplace.
When installed, it will allow you to wrap the Deploy Website to Azure task in your Release definition with Azure AppServices Stop and Azure AppServices Start tasks, effectively eliminating the lock issues.

Answer 2

Check if you are using "/" on the "Web Deploy Package" path for folder separators instead of "\".

i.e. change

$(System.DefaultWorkingDirectory)/My Project/drop/MyFolder/MyFile.zip

for

$(System.DefaultWorkingDirectory)\My Project\drop\MyFolder\MyFile.zip

I noticed that was the only difference between the one I was getting the error and the others (the Restart step I added was not helping). Once I modified the path, I got it working.

Sounds crappy, but fixed my issue.

Answer 3

Did you use the Build Deployment Template that sets the correct msbuild parameters for you for your package? You can see how here. I would create a build using that template and see if you have the same issues. If so ping me on Twitter @DonovanBrown and I will see if I can figure what is going on.

Answer 4

As a rule it is good practice to have any scripts or commands required to deploy your software to be checked into source control as part of your build. They can then be easily run repeatedly with little configuration at the build level. This provides consistency and transparency.

Even better is to have deployment scripts output as part of the build and use a Release Management tool to control the actual deployment.

Regardless having configuration as code is a mantra that all Dev and Ops teams should live by.