Welcome BugGuardian

Someone of you has maybe noticed the I did only few post in the last months. This happened because of two main reasons.

The first one is, as some of you already know, I moved in another country far away from home, with a completely different culture and language, to start a new adventure. This inevitably took a lot of time from the already small amount of spare time I have.

The second reason I wasn't so active here, that is also the reason of this post, is that I worked on a new project that I have released today: BugGuardian.

What is BugGuardian

BugGuardian is an Open Source library, written in C# like Shared Project, that allows to easily create a Bug work item on your Visual Studio Online account or on your on-premises Team Foundation Server 2015 in the case your application throws an Unhandled Exception.

It can also be invoked manually in try/catch blocks to keep track of handled exceptions.

It supports applications written with the .Net Framework v4.0 and above, and it can be used on every kind of project, including:

• Asp.net
• Asp.net MVC
• WPF
• Windows 8 / 8.1 Apps
• Windows Phone 8 / 8.1 Apps
• Universal App
• Universal Windows Platform Apps (Windows 10)
• and so on...

As I mentioned, it is OSS so you can find the sources on GitHub.

To let you install and use it without having to build the sources by your own, I have published it on NuGet. Just search for BugGuardian in the Package Manager GUI or run the following command in the Package Manager Console:
Install-Package DBTek.BugGuardian

Usage, support and Feedback

Refer to the project documentation to find examples about how to use this library. You can also find some code samples in the TestApps folder.

Anyway, just to make an example and to show it's really simple to use, this is the code you need to manage an exception and to open a Bug on your VSO / TFS:

using (var creator = new DBTek.BugGuardian.Creator())
{
    creator.AddBug(myException);
}

If you encounter any issue using this library, please let me know through the Issues page and I'll fix the problem as soon as possible!

I'm waiting for your feedback :)

I want to thank you my friend and fellow MVP Marco Minerva (@marcominerva) for the support, the patience and the Code Review.

Deploy a Web App to Azure with the Visual Studio Online Build

In this post we are going to see from sratch how to deploy a solution to an Azure Web App using the new Visual Studio Online Build platform.

To do it, we will use only the web portal of VSO.

Connect Azure to VSO

First of all we have to let Visual Studio Online know that we have an Azure account we want to use as deploy endpoint for our solution. Go the the Team Peoject Settings page (clicking on the button in the upper right corner of the project page), click on the "Services" tab, then on "Add new Service Connection" and then on "Azure".

At this point a pop-up will appear and we have to insert the ID of the Azure subscription which contains or will contain the Web App to publish, a name for it and the authentication mode.

We can use either a subscription certificate or the credentials.

When done, our Azure subscription and our VSO account will be connected (for this project).

Create the build definition

Now that we have linked VSO and Azure, let's go to the Build section of the project and create a new deployment build definition.

We eant to deploy to Azure, so in the "Deployment" section click on "Azure Website" (like shown in the image).

This creates a new build definition with some steps to configure.

Let's see how to proceed step-by-step.

The first one is the "real" build task. It's completely customizable but the most important thing is to define the solution file it has to use as build source. Select it like shown in the image, near the red arrow.

In the second step we have to set the how to execute the post-build Unit Tests. If we don't have unit tests (that is bad...) or we don't want to execute them (also this is bad :) ), we can safely remove this step using the "X" button that appears when the mouse pointer is over it.

The third step is the most important one for our scenario, because it publishes the build result to the Azure Web App.

In its settings there is a drop down where to select the target Azure subscription (if the previous Azure service connection worked properly). Then, in the "Web App Name" textbox, we have to write the name of the Web App we want to deploy. In theory this also appears as a drop down itself, but currently it doesn't load the existent Web Apps names (don't forget that the new Build platform is still in preview)

For this reaso, here I've written down some notes about the Web App name

• If we use a non-existent Web App name, it will create it on our Azure subscription using the selected region
• If we use a Web App name that doesn't exist in our subscription but which already exist in the selected region, the deploy process will fail
• If we use a Web App name that already exists in our subscription but it is in a region different from the selected one, the deploy process will fail
• If we use a Web App name that already exists in our subscription and it is in the selected region, the deploy will use it as target and will update it.

So pay attention about what we write :)

The two remaining steps allow us to index and to publish the application symbols (suggested, to have more information in the case of unhandled exceptions) and to publish the build artifacts somewhere.

When all the parameters are set we can go ahead and save our build definition, giving it a name.

We can also change all the default parameters in the upper tabs to customize the build process accordingly our needs.

Let's deploy!

Now that we have completed all the customizations, it's the moment to launch the build and to verify that the deploy works fine.

To start the build, click on the "Queue build" button in the build definition toolbar or in the contextual menu.

When we click on that button, VSO will queue a build based on our build definition and will execute it either on our servers or in a Microsoft Datacenter (if we have chosen to do it with the hosted agents).

Anyway, the build progress will be shown in the real time web console that appears as soon as the build is queued.

When is starts, it firstly execute the build and test tasks:

Then, if both are successful, the deploy to Azure:

When all the tasks will successfully finish, we have our web application deployed and running on Azure. Easy!

Create a RSS reader in an Umbaco 7 MVC Partial View

There are several way to create and embed a RSS reader in an Umbraco page: using custom controllers, using XSL macros, etc...

But wath if we want to use a normal MVC Partial View without to develop a custom controller?

Well, it is really simple to achieve this goal with just a few C# lines.

@inherits Umbraco.Web.Mvc.UmbracoTemplatePage
@using System.ServiceModel
@using System.ServiceModel.Syndication
@using System.Xml
@{
 string url = "http://your_blog_rss_url";
 XmlReader reader = XmlReader.Create(url);
 SyndicationFeed feed = SyndicationFeed.Load(reader); 
 reader.Close(); 
}

@foreach(var feedItem in feed.Items)
{ 
 <div class="col-md-6">
  <article>
   <div class="date">
    <span class="day">@feedItem.PublishDate.Day</span>
    <span class="month">@GetMonthName(feedItems[i].PublishDate.Month)</span>
   </div>
   <h4 class="heading-primary"><a href="@feedItem.Links[4].Uri">@feedItems[i].Title.Text</a></h4>
   <p>@(feedItem.Summary.Text + "... ") <a href="@feedItem.Links[4].Uri" class="read-more">read more <i class="fa fa-angle-right"></i></a></p>
  </article>
 </div>
}

As you can see, only a couple odlines are required. At this point we just have to include this partial view in the page where we want to see our RSS feed.
Obviously, you can change the layout (the one here is what I used in my project).

Only 2 notes:

1. I used "feedItem.Links[4].Uri" to retrieve the blog post url, this works if you use blogger. If you use other blogging platforms as sources, you'll have to check the Links collection to know "where" is the url you want.
2. The "@GetMonthName" is just an Helper to convert the "number" of the month into its name.

Cloud Load Test with Visual Studio Online - part 2: Visual Studio

This article is the second one of a series of 3 where I write about the Cloud Load Testing with Visual Studio Online.

In the first part I wrote about simple load tests execution using the VSO portal.

In this article I will approach a more complex (but more complete too) solution, the integration between Visual Studio and Visual Studio Online.

Remainder

Before to start with the Cloud Load Test execution, it's important to remind a couple of aspects:

• To use the Cloud Load Test functionality with VSO you need a MSDN Ultimate subscription
• The application you want to test has to be public exposed on the web (because the load test agents are in the cloud and need to reach our app)
• You can use a max of 20.000 free minutes of load test per month. They are "virtual user minutes", which means thet, i.e., if you execute a 2 minutes test with a constant load of 200 virtual users, you're going to consume 400 minutes..

Also, the Load test feature is available only on Visual Studio Ultimate/Enterprise.

That said, let's see how to setup and execute Load Tests with Visual Studio and Visual Studio Online.

Introduction

If we do a Load test with Visual Studio, we will have a plenty of settings we can configure, so this is the most tunable and customizable way to do such kind of tests.

Also, after the execution we will find a lot of information, data and charts about how our application performs under load.

Last but not least, we can do a multi step (multi page) test, even with pages under authentication, and we can record all the steps we want to do in the app in the same way a user will use it (so, no manual configuration is required for this task).

The Start

First of all, we have to create a test project in Visual Studio. The project template to use is "Web Performance and Load Test Project"

When we click on the "OK" button, VS creates for us the solution (as ever...) with a "WebTest1.webtest" project in it. This is not a "Cloud Test" project, it's a "Web Performance" one. We need this kind of project to instruct the load test in what to do.

In the upper left of the project, indeed, there is a small button with a big red dot: this is the button that allow us to record the "steps" in our application.

If we click on this button, it will open a browser session (typically IE) with a small panel on the left. This is the pane that "do the work", it's generated by the "Web Test Recorder helper" that VS installs on your machine.

As side note, remember to check if the plugin is enabled on the browser, if it isn't nothing will show.

Ok, now that the recording is active we can just visit and use the application we want to test just like a normal user will use it. We can also do some specific steps if we need to test specific pages, sections and so on.

To start the recording, write in the browser bar the url of the application and use it, the web recorder plugin will do all by itself.

When we have finished, just click on the "Stop" button in the recording pane. If we don't want to record some step, we can pause the recording and resume it later.

While we navigate our application, you will notice that a lot of "stuff" is added to the recording pane. Those are all the requests our app does.

If we select one of them and then click on the "comment" button, we can set a comment on it to be used later.

When we click on the "Stop" button, some magic happens. Firstly, Visual Studio grabs all the requests from the web recorder plugin, elaborates them and shows them in the webtest window. Then it tries to detect if we have some "dynamic parameters" in our test.

Dynamic parameters are the values that can change between one request and another one made in different moments: user tokens, user search, authentication, etc. If VS detect them, we will be prompted to decide what to do. We can decide to use the ones we recorded for every test it will do or if associate the params with "dictionary" where VS will pick different values at different times.

Another interesting aspect we can customize is related to "Request details". In this window we can decide if we want to insert a "think time" between requests (a delay) and, most important, what is for us the target time for the response. If during the test one request will have a response time greater than what we set, VS will consider the test as failed.

Now we have the webtest with all the steps and settings, we can add the Load test project.

The Load Test project

To add a load test to a web performance test, just right-click on project name, chose "Add" and than "Load test".

This action will start the "Load test wizard" which guides us through the load test setup.

On the first step, we have to select how to manage think times (delay between requests): we can use the "recorded times" (the ones that happens during registration), normal distribution (an average based on recorded times) or to remove all the think times. We can also insert a think time between iterations of the test.

In the second step we have to decide how much load we want to generate, and how to generate it.

We can select to have a constant load (the test will start with N users and will continue with the same number of users until the end) or to have a "step load".

In the image, for example, I decided to start the test with 10 users and then to add other 10 users every 10 second until a maximum of 200 users. 

Step load can be really interesting because in that way we will discover how our application scales based on the incremental load.

In the next step, we have to instruct the load test in what to do. For that reason, we will add the web performance test we created before.

Click to "Add", select the performance test and click to "Ok". The test will be added to the "test mix" window. It's called "Test Mix" because we can add as many test as we want, and we can decide the distribution of each test over the total. In this example we have only one test so the distribution will be 100%.

We can also decide, in the next steps, how to mix network types for source users (warning: when I wrote this article VSO supports only "LAN" network type) and also the kind of browser engines we want the test agents use to do the requests.

As you can see in the image, we can select from a list of different browser engines and we can also set the distribution between the user agents.

In the last step, we can customize the load test duration.

We can select between fixed time duration or number of test iterations to be done regardless of the time. If we select a fixed time (2 minutes in my example), we can also insert a "Warm-up time" (10 seconds in the example). During this time some dummy requests will be sent against the application and no result data will be collected. This is extremely useful if we has to test an application that could have a "cold start" (think for example an application hosted on IIS that could not be used for a while and than IIS "deactivated" the app pool) and to not have some false-positives in the test result.

Clicking on "Finish", Visual Studio will generate the load test project and saves it in our solution.

Test execution

Now that we have all the stuff ready, we can start our test execution. But before, only a little more customization. Indeed, we want to execute our load test using the Visual Studio Online Cloud Load test feature, but noone has said this to our local Load Test project.

To do it, open (double click) the "Local.testsettings" file in the solution and change the "Test run location" to Visual Studio Online.

Note that if you have logged in to Visual Studio with an account that own a VSO subscription, this step is not necessary because VS already selected it for you.

Ok, let's start the test. Click on the "Start button" in the upper left.

But what happens when you start the test?

Visual Studio connects to Visual Studio Online and queues the test. VSO then creates an on demand virtual lab in some Azure datacenter and configures the test agents on the VMs, with the given settings.

As soon as the lab is ready and configured, the test starts. We have configured a warm up period, so it starts with it and we can see no data is collected.

Then, the agents start to generate traffic to the given pages of our application (as used in the recording) and the results are posted back to Visual Studio in near real time. In this way we can have a preview of the test outcome.

Now we can wait the test execution ends to have the full resultset.


Results

When the test completes, we are given the results and the achieved performances. We have a lot of information available.

We have the average responses time, with also the min and the max, together with average test times, average page times and user load.

We can also see from the chart and from the info that the virtual users grew from 10 to 120 (I set 200 as maximum but it didn't have time to reach it 'cause the test lasted only 2 minutes) and how the tested application scaled.

Also in the "Throughput" page we can see other useful informations.

In this example we don't have errors, but if they had occurred we'll find them with the generic cause, the specific type and the given error message.

But this is only a small subset of all the information we can have. If we click on the "download report" link, in the upper, VS will download the whole resultset from Visual Studio Online and we can enjoy a sheet plenty of data and charts which can help us to better understand how our application performs under certain load.

Conclusions

This kind of Load Test is the most complete we can do. As we have seen, it gives us a lot of informations, metrics and charts to better understand our application behaviours.

Moreover, the setup of these tests is simple but very customizable and in a while we can have a huge number of useful info.

Stay tuned for the 3rd and last article of this series, which will be about Load Test APIs.

Cloud Load Test with Visual Studio Online - part 1: Web panel

This article is the first of a series of 3 where I'll write about the Cloud Load Testing with Visual Studio Online.

In this first part I'm going to talk about simple load tests execution, directly using the using the VSO portal.

Introduction

Before to start with the Cloud Load Test execution, it's important to specify a couple of aspects:

• To use the Cloud Load Test functionality you need a MSDN Ultimate subscription
• The application you want to test has to be public exposed on the web
• You can use a max of 15.000 minutes of load test per month. They are "virtual user minutes", which means thet, i.e., if you execute a 2 minutes test with a constant load of 200 virtual users, you're going to consume 400 minutes..

That said, let's see how to setup and execute those Load Test with the Visual Studio Online web interface.

The start

First of all, you have to log in into your VSO web portal and click on "Load test" on the main dashboard's menu.

Atfer that, it shows the settings page. How you can see, it's a single form: the available settings are a bit limited but more than sufficient to do a generic load test over our app.

The first parameter to set is the url of the page to test (it's not possible to execute a multi-step load test from this interface) which can be the home page or, like in the example, what page you want. The only constraint is that the page must be accessible on the internet without credentials.

The second value to insert is the test name: it a free text, useful as reminder.

Below of these params there are other 4, named "Test settings", useful to better set up the key aspects of the load to apply.

• User Load: with this setting you can define the number of concurrent users that will connect to the give url. Allowed values are 25, 50, 100 and 200
• Run duration: it's the duration of the entire test. Possible selections are from 1 to 5 minutes
• Think-time: it's the consecutive requests' delay time. It's useful to avoid the intervention of anti-hammering and anti DoS systems. It's possible to set a waiting time of 1 second (default) or 5 seconds
• Browser distribution: this selection sets the percentage of browser usage you want to simulate. Choosing, for example,"IE 80%, Chrome 20%" the test will be executed with agents that use Internet Explorer engine and Chrome engine by the given percentages

Setted up these setting, just click on the "Test now" button to start the test.

Test execution

But what happens when you start the test?

Visual Studio Online creates an on demand virtual lab in some Azure datacenter and configures the test agents on the VMs, with the given settings:

As soon as the lab is ready and configured, the test starts. The agents start to generate traffic to the given url and the results are posted back to our browser in near real time. In this way we can have a preview of the test outcome.

In the image we see, i.e., that at about 50 seconds there is a "hole" in the request per second that the site was able to manage, associated with a huge increase of the response time. Using these data we could start an analysis activity over our application or our infrastructure to understand why and where this anomaly happened.

Results

When the test completes, we are given the results and the achieved performances.

Near the chart we have seen before, we have a couple of other informations.

First, we have the average response time. A value under 0,1 seconds is considered good, between 1 second and 0,1 seconds is "not so good", more than 1 second is bad.

After the response time, there is the number of total requests done to the web app.

Finally, there is an indication of any requests that are not completed successfully or generated an error on the application.

Below these values there is also a table with the eventual errors.

In this example we don't have errors, but if they had occured we'll find them with the generic cause, the specific type and the given error message.

Conclusions

This kind of Load Test isn't the most complete we can do but it's however sufficient if we want to have some info about the performances and the load managed by our application

Moreover, the setup of these tests is extremely simple and in a while you can have a huge number of useful info.

Instead, if what you need is a deep load test where you can do a step-by-step navigation, maybe with credentials... don't miss my next article of this series.