You have automated a deployment of an ASP.NET website to Azure (App Service), using Visual Studio Team Services (VSTS). Deployment went fine (no errors) but when you try to access the website you get an runtime error such as the following:

You must be thinking that I should run some smoke tests after the deployment to detect problems like this one, and you’re absolutely right. But, believe me or not, there are still a lot of companies that have no unit tests or just a few – let alone integration/smoke tests! Believe me, I’ve been there

In that case, there are quick and easy ways to run some sort of smoke tests. For example, you can configure a Powershell task as follows:

In short, Invoke-WebRequest sends an HTTP request to a web page (defined in the $(HomePage) variable). If the page returns a 500 error the Powershell task and consequently the deployment will fail:

Deployment log:

That’s it! As a final note, the task configured above contains inline script, which should be avoided (I did it for demonstration purposes only). All source code, scripts,configuration, etc should be under source control.

You probably noticed that .NET Core builds take much more time compared to the traditional .NET builds. For example, when you run the command dotnet restore you might have noticed something like this being logged:

As you can see, caching of the packages took almost 1 minute! As suggested in Stop wasting time during .NET Core builds, adding the following environment variables to your build definition can reduce the build time:

So basically DOTNET_SKIP_FIRST_TIME_EXPERIENCE will prevent the caching of the packages on the build machine, and NUGET_XMLDOC_MODE will prevent the download of the XML documentation for the packages. Unfortunately I couldn’t find much documentation about these variables, but check the blog post above for more details.

Unable to start debugging on the web server. Could not start ASP.NET debugging. More information may be available by starting the project without debugging.

My initial reaction was to check if there was something wrong in IIS, and I was right: the application pool used by the application I wanted to debug was stopped!

At that moment I realised that I changed my Windows password 2 or 3 hours before trying to debug the application. Given that the application pool was running under my credentials, all I had to do to fix the issue was to right-click the application pool and go to Advanced Settings > Identity and update my password

So basically the TransformXml task was failing because the file Config\AppSettings.config was checked out as read-only in the build server.

Fortunately there is an easy workaround. The trick is to apply the XML transformations to a temp file and then use the Copy task with the OverwriteReadOnlyFiles attribute set to “True” to overwrite the file Config\AppSettings.config:

Even though there was an error executing the script, Bamboo was setting the status of the Deployment to Success. Why? Because the exit code returned by the powershell script is always 0 (zero means successful execution).

After some research I was able to find a way to return the correct exit code in case of failure. I added the following lines to the top of my powershell script:

trap
{
write-output $_
exit 1
}

The trap statement includes a list of statements to run when a terminating error occurs – in this case, every time an error occurs the error message will be displayed and then the script will return a correct exit code indicating a failure. I am returning 1 but any value different from 0 (zero) will do the trick