Post navigation

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.

I’m using Visual Studio Team Services (hosted agent) to automate the builds and deployments of .NET Core solutions.

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.

This happened to me today – I was getting the same error whenever I tried to debug an ASP.NET application using Visual Studio:

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:

As part of an deployment project on Bamboo CI, I was running a powershell script to deploy an ASP.NET application to a Cloud Service on Azure.

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🙂

This is a very common scenario that I’ve seen in many different places over the last few years – each method has some code wrapped in a try-catch block. To get rid of the code duplication is easy, we can move the try-catch block to a new method that will take a delegate as a parameter (code to be executed):

A few months I had to estimate how much time/effort was involved in localizing one .NET application. As part of this task I had to search for all the hard-coded strings in the source code that should be localizable, which is a tedious and very time-consuming task.

The good thing is that Resharper has good localization support which can save you many hours or even days of work – imagine having to go through all files and search for the strings manually! In this post I’ll show you how you can use Resharper to detect localizable strings and how you can enable or disable localization for a particular project, class, method or even an individual string.

I’ve been using Bamboo CI Server for the last few months to automate builds and deployments. I like the tool because it has good integration with Jira (both tools are from Atlassian), it’s easy enough to configure new builds and deployments, triggers, notifications, etc.

But I realised that something important was missing: Bamboo allows you to add a test runner task in a build project but not in a deployment project! This means that you can’t run tests after a successful deployment (smoke tests, integration tests, …), at least not without a workaround.

The trick is to configure your test runner as an executable in Bamboo. These are the steps in order to configure NUnit and run tests in a deployment project (it should work for any other test runner):

1. Add a new executable for NUnit

Go to Bamboo Administration and click on “Executables” on the left panel.

Click on “add an executable as a server capability”

Add the path to NUnit Console and a label for the new executable. It is important to set the type to “Command” in order to use it in a Deployment project:

Click on the “Add” button to save the new command.

2. Add a new deployment task to run the tests

You can either add a new task for the tests to an existing deployment or add a new deployment project that will only run the tests.

I decided to add a new deployment project that will be triggered after a successful deployment because it’s easier to understand if there is actually a problem with the deployment itself or if the integration tests are failing. Also, this way I am able to run the tests at any time without having to deploy the application.

Whatever your choice is, add a new “Command” task to the deployment project:

In the “Executable” dropdown you should be able to find the command you configured for NUnit. Add arguments and environment variables if necessary:

Save the task and run the deployment. This is an excerpt of the generated log that contains the test results:

As you can see, for each model you have an if statement. This works fine if you only need to create 2 or 3 validators but if you need more your code will get bigger and bigger and will be harder to read/maintain. The same applies to switch statements.

The first step to solve this problem is to create a Dictionary to store the validators. The key of the Dictionary will be the type of the model and the value will be a delegate that creates an instance of the validator for that model:

The scenario – I am working on an ASP.NET web site that is hosted on Azure as a Cloud Service.

I have automated both the build and the deployment to the cloud using theBamboo build server. The build compiles the solution, runs the unit tests and generates the deployment packages that are used by Bamboo to deploy the site to Azure.

I could use Bamboo to manage all deployments but given that Cloud Services offer out-of-the-box support for blue-green deployments I decided to take advantage of both systems. This is how I have organised things:

1. Deployment to Staging

Deployment to Staging is performed by Bamboo. Automated tests are executed as part of the deployment to check if everything is working as expected. Additional manual tests should be executed as well before deploying to Production.

2. Deployment to Production

This is done using the Azure Management Portal – simply click on the Swap button and traffic will be routed to the Staging environment, which now becomes the Production environment.

3. Rolling Back

Something went wrong? No problem, click on the Swap button again to switch the environments – it’s just as simple as that.

You can use your Continuous Delivery server in conjunction with Azure Management Portal to manage your deployments to the cloud – consider all the advantages and disadvantages and use the functionalities of each system that makes your life easier🙂