Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / operating-systems / Windows

Custom VSTS Task: Code Analysis & Email

4.00/5 (1 vote)
16 Dec 2015CPOL5 min read 16.7K  
Custom VSTS Task: Code Analysis & Email

I just wanted to take a quick moment to talk about our latest update to the VSO Tasks GitHub repository (found here). We've got two new custom tasks to assist with the Build / Release vNext and provide some additional functionality.

For those of you who aren't aware if you are using Visual Studio Team Services (VSTS) (formerly called Visual Studio Online(VSO)), you have the ability to upload custom tasks to add to either your build pipeline, or release pipeline. The newest version of Release Management vNext has gone completely browser based, and provides a wealth of new functionality and is significantly easier to use. For more information on Release Management vNext, check out our previous post found here.

But all that being said, we are pretty excited to talk about our newest set of custom tasks to be added to the VSO Task repository.

Code Analysis

As development shops mature, Code Quality becomes a problem that they grapple with trying to get a handle on. The overall quality of your code dictates the ability of developers to maintain and even grow your application. A simple fact of life is that bad code takes longer to maintain, and can limit your flexibility when it comes to growing your application. Now Visual Studio does have great tools to provide support for Code Analysis (formerly called FxCop). For more information on the Code Analysis features of Visual studio, look at the MSDN article found here.

But even with how great that tool is, one of the problems you will consistently run into is making running it a part of your process. We all get busy and its easy to forget to run a manual process like this and distribute it to everyone who should be seeing it.

That's where our new task comes into the picture. We've built a custom task that can be added to your build or release pipeline that will allow you to execute Code Analysis on a collection of DLLs, and then send the results off to one or more people for review.

To start with, you can find the custom task here. And with it in GitHub is a set of instructions for how to upload that task into your VSTS Tenant.

Let's start by going to your build definition, which probably looks like what's shown below:

0.1 - Build Definition

From there, you click the "Add Build Step" button and you will be prompted with the following menu. The Code Analysis task is found under the "Utility" menu as shown below.

0.2 - Add Code Analysis

After adding the build step, drag it to the appropriate place in your build pipeline and you should see the screen below, as we next need to configure the build pipeline:

0.3 - Blank Code Analysis

So for configuring this code analysis step, refer to the definitions of the parameters below:

  • Rules to Run: Code Analysis within Visual Studio contains collections of rule sets and this dropdown gives the ability to select a ruleset to execute. Select the ruleset you wish to run as part of this build step.
  • Build Directory: This denotes the directory of the DLLs that you want to run code analysis on. More often than not, this will be the bin directory of your application.
  • File's: You have the ability to enter multiple DLLs here, you just need to put in the appropriate file names in a comma separated list.
  • Output File: Code Analysis will generate an output file that will contain the results of the report. It utilizes a "*.xsl" file by default within Visual Studio to determine the structure of the output. Please put a ".html" file path into this to configure the results as an easy to read html file.
  • Include Summary: Code Analysis can provide an easy to read summary of the results and this denotes if it should be included in the report.

Additionally, there are some extract parameters underneath the advanced configuration that are available.

0.4 - Advanced Configuration

  • Verbose: Provides additional logging and description within the report for review.
  • Ruleset Directory: By default, this script checks for Visual Studio 2013 or Visual Studio 2015's ruleset directory. If you have a custom result directory you would like to be referenced, define it here.
  • XSL Template: By default, this script will use the default FxCopReport.xsl found within Visual Studio 2013 or Visual Studio 2015. But the Code Analysis generates XML data results, so if you would like to use a custom .xsl template you can define the path of that here.
  • FxCop Execution Path: As with above, this task looks for Visual Studio 2013 or Visual Studio 2015's FxCop instance, but if you have a different path to the Fxcopcmd.exe you would prefer be used, you can indicate that here.

Once configured, you will see the following:

0.5 - Fully Configured

Email

To go along with the above task, that Code Analysis report doesn't do a lot of good sitting on the build server. So we've added an additional custom task that allows you to generate emails as part of your build pipeline.

The custom email task can be found here.

From the above link, once again you will find instructions on how to upload this custom task into your VSO tenant.

With your new build definition setup as shown below:

0.6 - Adding Email Current definition

Click "Add Build step" and you will find it listed within the "Utility" section as shown below.

0.7 - Adding email step

You will then see the blank email step added to your build definition.

0.8 - Blank Email Definition

So for configuring this email step, refer to the definitions of the parameters below:

  • From: Allows you to denote the email address used to send the email
  • To: Allows you to denote a comma separated list of intended recipients
  • Subject: Define the subject of the email
  • Body: Allows for your to put in the body of the message you are sending
  • Attachments: This allows for a comma separated list of attachments to be added to the email, and this is where you would attach your code analysis report from above.

Once you've populated your email step, it will look similar to this:

0.9 - Email fully defined

Now I know what you are thinking, and it's that the step can't possibly be complete, and you are correct. Where's the SMTP information? Where do I define my server for sending that email.

Because we forsaw that build/release definitions could contain multiple email steps, we moved that information to the "Variables" tab of your definition. For this email step to work, you will need the following variables, as shown below:

0.10 - Email variables

This allows you to define that information one time and use it over and over again.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)