If you are working in a Windows enviroment there’s a good probability you are using Microsoft’s SQL Server and you will have to monitor and fine-tune it’s usage to prevent problems and identify wrong usages.

Telegraf already has a plugin for sql server that will extract information for your instance by executing a query. While this works well it has two problems:

• due to a bug it can only connect to SQL server 2008 R2 SP3 (this is a minor problem, I hope your SQL Servers are at least updated to a version which has not run out of support)
• it extracts a lot of data most of which is useful only in limited cases.

To make it simple we can craft a configuration which includes only the most relevant and important counters. As in the case of an application server you will need the same base data:

• use the disk, cpu and mem plugins
• Network Interface :
• “Bytes Received/sec”
• “Bytes Sent/sec”
• “Bytes Total/sec”
• Processor:
  • ”% Idle Time”
  • ”% Interrupt Time”
  • ”% Privileged Time”
  • ”% User Time”
  • ”% Processor Time”
• LogicalDisk :
  • “Disk Bytes/sec”
  • “Disk Read Bytes/sec”
  • “Disk Write Bytes/sec” (all istances except _Total)

Now to the SQL Server- specific Performance counters (replace INSTANCE with the name of your instance, there can be more than one on a single server):

• MSSQL$INSTANCE:Buffer Manager :
  • “Buffer cache hit ratio”
  • “Database Pages”
  • “Free list stalls/sec”
  • “Page life expectancy”
  • “Page lookups/sec”
  • “Page reads/sec”
  • “Page writes/sec”
• MSSQL$INSTANCE:Databases:
  • “Active transactions”
  • “Transactions/sec”
  • “Write transactions/sec”
• MSSQL$INSTANCE:General Statistics:
  • “Processes blocked”
• MSSQL$INSTANCE:Latches:
  • “Average Latch Wait Time (ms)”
  • “Latch Waits/sec”
  • “Total Latch Wait Time (ms)”
• MSSQL$INSTANCE:Locks:
  • “Average wait time (ms)”
  • “Lock Requests/sec”
  • “Timeout locks (timeout > 0)/sec”
  • “Lock Timeouts/sec”
  • “Lock Wait Time (ms)”
  • “Lock Waits/sec”
  • “Number of Deadlocks/sec”
• MSSQL$INSTANCE:SQL Statistics:
  • “Batch Requests/sec”
  • “SQL Compilations/sec”
  • “SQL Re-Compilations/sec”
• MSSQL$INSTANCE:Transactions:
  • “Free Space in tempdb (KB)”
  • “Transactions”
  • “Version Cleanup rate (KB/s)”
  • “Version Generation rate (KB/s)”
  • “Version Store Size (KB)”
  • “Version Store unit count”
  • “Version Store unit creation”
  • “Version Store unit truncation”
• MSSQL$INSTANCE:Wait Statistics:
  • “Lock waits”
  • “Log buffer waits”
  • “Log write waits”
  • “Memory grant queue waits”
  • “Network IO waits”
  • “Non-Page latch waits”
  • “Page IO latch waits”
  • “Page latch waits”
  • “Thread-safe memory objects waits”
  • “Transaction ownership waits”
  • “Wait for the worker”
  • “Workspace synchronization waits”

These performance counters will give you a pretty complete view of your SQL Server behaviour allowing you to inspect and correlate performance problems in your applications with the state of your database.

One question arises: what data to capture? This depends on the role of the server where the collecting agent is installed.

For an application server we can collect some basic data:

• we can use Telegraf inputs cpu, disk e mem
• some useful Performance Counters to collect are:
  • Processor : “% Idle Time”, “% Interrupt Time”, “% Privileged Time”, “% User Time”, “% Processor Time” (only _Total)
  • Network Interface: “Bytes Received/sec”, “Bytes Sent/sec”, “Bytes Total/sec” (all istances except _Total)
  • LogicalDisk : “Disk Bytes/sec”, “Disk Read Bytes/sec”, “Disk Write Bytes/sec” (all istances except _Total)

If the server hosts web applications you can add these Performance Counters:

• ASP.NET : “Requests Queued”
• ASP.NET Apps v4.0.30319 : “Requests/sec”, “Sessions active”
• Web Service: “Connection Attempts/sec”, “Current Connections”

If you are using MSMQ:

• MSMQ Queue : “Messages in Queue” (you can read them all or specify individual queues),
• MSMQ Service : “Total bytes in all queues” (this is important as MSMQ by default has a 1GB limit for messages saved and will refuse new messages when that limit is reached)

If you remember from the previous post the four areas to consider are:

• Data collection
• Data storage
• Data visualization
• Alerting

Data collection

As we said one of the most important things is the ability to read Windows Performance Counters and write data to our chosen storage. Here the solution was simple Telegraf.

Telegraf can be easily installed as a Windows Service and most importantly:

• can save to numerous type of storage allowing you flexibility in choosing the storage type
• already has numerous plugins allowing you to scrape data from numerous sources (if a plugin does not exists it’s simple to create a new one if you know a little Go)

Data storage

The second choice to make regarded the storage layer. While using Telegraf allows a great degree of flexibility we had to choose a solution with a good Windows support, low hardware requirements and able to be queried by the tools we chose for data visualization and alerting.

The choice was simple, we chose InfluxDb which can be installed as a WIndows service, has low requirements and integrates well with the other tools in the stack.

Notably it has also a concept of data retention allowing you to specify an automatic cleanup of your data after 30 days.

Data visualization

To visualize the collected data we chose to use Grafana which is able to plot graphs reading directly from InfluxDb and from a lot of other data sources giving you a lot of flexibility and allowing you to easily navigate and correlate your data.

Alerting

Initially we tried to use for this part Grafana new support for alerts but we soon realized it was too limited to work well (no multiple levels, no different alerting rules, …) so we switched later to Bosun, a monitoring and alerting tool created by Stack Exchange. This tool can easily query InfluxDb, allows you to define complex rules and tweak them over time.

Also it has a dashboard with all active alerts where you can handle them byacknowledging them or closing when solved.

Reamrks

While this solution has proved to work well, other combinations are possible.

• swapping Grafana and Bosun for Chronograf and Kapacitor (produced by the same developers as InfluxDb and telegraf)
• using Prometheus as data storage
• using ElastiCsearch as storage, Kibana for visualization and Watcher for alerting

One of the challenges is collecting informations about your VMs, some important services (SQL Server, RabbitMQ, ElasticSearch,..) and your virtualization enviroment to be able to inspect them or be alerted in case of problems (or better before they happen).

To setup this kind of data collection and monitoring there are four area to consider. I will describe them and then propose a solution I’ve found works really well with minimal setup and is easy to configure.

The four areas to consider are:

• Data collection
• Data storage
• Data visualization
• Alerting

Data collection

The first step is deciding what data you need to collect and find a program that can read it at a pre-defined interval and store where you want it. While there are many tools of this type, we need one that is able to work on Windows and adapt to it’s peculiarities. This means having something able to read Windows Performance Counters.

Performance Counter are a Windows-only mechanism that is used to report values about the operating system but can be also used by applications like SQL Server. Some examples are:

• number of bytes of memory used
• number of messages in a MSMQ queue
• output troughtput for every network card
• number of phisycal reads per seconds (SQL Server)

The full list of these counters can be seen from Performance Monitor, where they are divided in categories for easier navigation. The Performance Monitor interface is a throwback to the nineties but we need only the list of counters reachable when adding a new counter.

Pay attention to the fact that Performance Counter names are localized so mind the possibility that there may be a difference in name between you local computer and production servers.

Options: Telegraf, Collectd, scollector, Elastic Beats,….

Data storage

The second and most important part is the storage of your collected data. The usual solution is using a time-series database which is a form of database specialized in saving and reading time-series (metrics). Multiple options are available that can easily run on windows like InfluxDB and Prometheus. Your choice should be based primarily on two factors:

• can my data collector program write to the chosen storage?
• can I easily visualize data from the storage?

Availability and disaster recovery may play a part in your choice but after running our chosen system for a year we treat this data as important but disposable, meaning we have no high availability and we accept the possibility of losing the data. We also keep only the last thirty days of data, a compromise allowing us to inspect trends in a metric but limiting the size of storage needed.

Another important factor to consider is how much data your chosen tool is able to ingest. If you collect 10 metrics per machine every ten seconds what can work with a hundred server may fail with ten thousand. Fortunately most are able to ingest massive quantities of data with limited resources and if this becomes a problem you can use multiple databases, partitioning the resources by type or group of servers.

Options: Prometheus, InfluxDb, ElasticSearch, Graphite, OpenTSDB

Data visualization

The third part is data visualization, for which you need a tool that is:

• easy to use
• able to show the current status at a glance
• able to let you inspect and correlate historical data to pinpoint problems in a post-mortem
• easily configurable by everyone

While this part seems “easy” a good visualization tool will make the difference. It will help you correlate a spike in your response times with anomalies in your database metrics. It will help you pinpoint configuration errors in your servers. It will let you uncover stray queries that every two hours read the entire database to generate a report. In short a good visualization tool will let you discover so much more about you systems and applications than you ever thought existed.

The fourth point is also important. While creating standard visualizations is really useful it should also be possible to explore the data freely by anyone without having to ask to a central group to create a new visualization every time it is needed. This will let everyone move freely witout having to wait for someone else.

Options: Grafana, Kibana, Chronograf,…

Alerting

The last part is alerting on the collected data. Ideally you want to be able to:

• define rules about possible problems with levels of importance (at least warning and critical)
• having the ability to quickly change the defined rules
• having the possibility to define alerting destinations
• having the possibility to view at a glance the status of all your alerts and track their status over time

Defining different levels of importance will let you see problems way before they matter, like full disk storage, and give you time to act or ignore them during the night. Having the ability to tweak these rules will let you cut down on the number of alerts which can lead you to alert fatigue if left unchecked making you ignore an important alert because it is buried in another thousand of less important notifications.

If you can define different alert destinations you can escalate the important things while leaving the minor ones to be handled when you have time. Having also a dashboard which lets you see all active alerts, their status and past status will let you more easily coordinate with others in your team.

Options: Grafana, Bosun, Chronograf

First solution: Sharepoint

This was the solution implemented when I was hired. It basically boils down to a website where documents can be uploaded in a folder-like structure with permission to upload, read and modify them. While it worked it had some serious problems:

• lack of search across documents
• permissions had to be requested to an administrator to view documents (this could be avoided by giving read permissions to everyone in truth)
• permission had to be requested to modify documents, even to correct a typo
• finding documents was not easy as they could be there but you could be missing the necessary permissions to see them
• its folder-like structure allowed to organize content in a logical way

Second solution: The wiki

In the attempt to solve some of these problems we decided to use a Wiki to write our documentation. While it solved some problems it had some disadvantages:

• we had full text search across all documentation
• permission were not needed allowing everyone to contribute and amend the documentation with full traceability
• a logical organization of the documentation was missing requiring each developer to hand mantain it by using links in every page making it tedious and error-prone

The final solution

At this point we realized we needed a diferent solution, something allowing us to:

• organizing in a hyerarchical way our documentation easily
• allowing everyone to easily update it

To reach this objective we used Metalsmith to create a git repository containing our documentation written in Markdown. Each time someone edits a page, the repository is built by the CI system and a static site is deployed. The structure of the site reflects exactly the on-disk folder structure allowing the topics organization.

In this configuration no permissions are needed as every edit is reflected in the source control history and can easily be reverted.

If you want to try it you can download a personalizable skeleton at https://github.com/Bjornej/KnowledgeBase. To run it just

npm install
node -harmony build.js

an your static site will be built.

When I started developing my first application what was taught to me was: verify that it builds and deploy it to a network folder with the Visual Studio Publish option. It worked fine as I was working alone but it had numerous problems:

• a build was not reproducible exactly, as it didn’t match exactly what was in source control but what was on my computer
• I had to remember to build and deploy the correct configuration which was different from the one used to develop
• in a strange case my computer was the only one able to build the application due to specific version of a compiler only I had installed

All these things summed up to many little problems so I started looking for better solutions, reading books about continuous delivery and deployment. At the same time the number of applications we were working one augmented magnifying the problems we had so I started working on Bazooka a tool to automate application deployments.

Last week I was looking at its statistics page and noticed one thing: in less than two years (from June 2015 to February 2017) over thirty developers worked on ninety applications making over ten thousand deploys.

As you can see usage has been steady with an increase during summer months as many of our applications have a usage peak in the summer.

Over 90 applications were published some of which are very active while others are in maintenance mode and experience only a few deploys per year

During these two years many bugs have been fixed and features added but there still are some that could make for an easier deployment experience like release promotion through enviroments but this is an argument for another post

• the ability to self host in process without IIS making it perfect to create standalone services
• its design based on dependency injection

While we would love to be able to use the .NET Core version there are too many libraries that have not been ported still so we are forced to run on the full .NET framework and keep an eye on future developments to use the .NET Core framework.

While this solves many problems some libraries that integrated with ASP.NET have not been ported, in our case what was missing was the OData support. Searching online you can found some informations about it:

• https://github.com/OData/WebApi/issues/772
• https://github.com/OData/WebApi/issues/229
• https://github.com/OData/WebApi/issues/744

but all signs point to the porting work being stopped due to other priorities. This was a show stopper for us as we rely on OData to easily connect a React component representing a sorted, paginated and filterable table directly to a data source without having to code all possible queries.

Fortunately we didn’t rely on the classic ODataController but instead bound ODataQueryOptions as an action parameter and the built some extension method to apply them and obtain a PageResult (a type representing your data along with the total number of elements in the collection which is necessary to draw a paginated table).

    [HttpGet]
    public PageResult<Person> Teens(ODataQueryOptions opts)
    {
        return dataSource.Persons().Where(x => x.Age < 18).PagedFilter(opts);
    }

The main problem is that this type by default won’t bind to the request as this was done in WebAPI from ODataQueryParameterBindingAttribute. As the source is easily available thanks to Microsoft new openness we can easily adapt it to an IModelBinder and IModelBinderProvider used by Asp.NET Core

public class ODataQueryOptionsModelBinder : IModelBinder
{
    private struct AsyncVoid
    {
    }

    private static MethodInfo _createODataQueryOptions = typeof(ODataQueryOptionsModelBinder).GetMethod("CreateODataQueryOptions");

    private static readonly Task _defaultCompleted = Task.FromResult<AsyncVoid>(default(AsyncVoid));

    public Task BindModelAsync(ModelBindingContext bindingContext)
    {
        if (bindingContext == null)
        {
            throw new ArgumentNullException("bindingContext");
        }
        
        var request = bindingContext.HttpContext.Request;
        if (request == null)
        {
            throw new ArgumentNullException("actionContext");
        }

        var actionDescriptor = bindingContext.ActionContext.ActionDescriptor;
        if (actionDescriptor == null)
        {
            throw new ArgumentNullException("actionDescriptor");
        }


        Type entityClrType = GetEntityClrTypeFromParameterType(actionDescriptor) ?? GetEntityClrTypeFromActionReturnType(actionDescriptor as ControllerActionDescriptor);

        Microsoft.Data.Edm.IEdmModel model = actionDescriptor.GetEdmModel(entityClrType);
        ODataQueryContext entitySetContext = new ODataQueryContext(model, entityClrType);
        ODataQueryOptions parameterValue = CreateODataQueryOptions(entitySetContext, request, entityClrType);
        bindingContext.Result = ModelBindingResult.Success(parameterValue);

        return _defaultCompleted;
    }

    private static ODataQueryOptions CreateODataQueryOptions(ODataQueryContext ctx, HttpRequest req, Type entityClrType) {
        var method = _createODataQueryOptions.MakeGenericMethod(entityClrType);
        var res = method.Invoke(null,new object[] { ctx,req}) as ODataQueryOptions;
        return res;
    }

    public static ODataQueryOptions<T> CreateODataQueryOptions<T>(ODataQueryContext context, HttpRequest request)
    {
        var req = new System.Net.Http.HttpRequestMessage(System.Net.Http.HttpMethod.Get, request.Scheme + "://" + request.Host + request.Path + request.QueryString);
        return new ODataQueryOptions<T>(context, req);
    }

    internal static Type GetEntityClrTypeFromActionReturnType(ControllerActionDescriptor actionDescriptor)
    {
        if (actionDescriptor.MethodInfo.ReturnType == null)
        {
            throw new Exception("Cannot use ODataQueryOptions when return type is null");
        }

        return TypeHelper.GetImplementedIEnumerableType(actionDescriptor.MethodInfo.ReturnType);
    }

    internal static Type GetEntityClrTypeFromParameterType(ActionDescriptor parameterDescriptor)
    {
        Type parameterType = parameterDescriptor.Parameters.First(x => x.ParameterType == typeof(ODataQueryOptions) || x.ParameterType.IsSubclassOf<ODataQueryOptions>()).ParameterType;

        if (parameterType.IsGenericType &&
            parameterType.GetGenericTypeDefinition() == typeof(ODataQueryOptions<>))
        {
            return parameterType.GetGenericArguments().Single();
        }

        return null;
    }
} }

the ODataModelHelper

public static class ODataModelHelper
{
    private const string ModelKeyPrefix = "MS_EdmModel";

    private static System.Web.Http.HttpConfiguration configuration = new System.Web.Http.HttpConfiguration();

    internal static Microsoft.Data.Edm.IEdmModel GetEdmModel(this ActionDescriptor actionDescriptor, Type entityClrType)
    {
        if (actionDescriptor == null)
        {
            throw new ArgumentNullException("actionDescriptor");
        }

        if (entityClrType == null)
        {
            throw new ArgumentNullException("entityClrType");
        }

        if (actionDescriptor.Properties.ContainsKey(ModelKeyPrefix + entityClrType.FullName))
        {
            return actionDescriptor.Properties[ModelKeyPrefix + entityClrType.FullName] as Microsoft.Data.Edm.IEdmModel;
        }
        else
        {
            ODataConventionModelBuilder builder = new ODataConventionModelBuilder(ODataModelHelper.configuration, isQueryCompositionMode: true);
            EntityTypeConfiguration entityTypeConfiguration = builder.AddEntity(entityClrType);
            builder.AddEntitySet(entityClrType.Name, entityTypeConfiguration);
            Microsoft.Data.Edm.IEdmModel edmModel = builder.GetEdmModel();
            actionDescriptor.Properties[ModelKeyPrefix + entityClrType.FullName] = edmModel;
            return edmModel;

        }
    }
}

the IModelBinderProvider

public class ODataModelBinderProvider : IModelBinderProvider
{
    public IModelBinder GetBinder(ModelBinderProviderContext context)
    {
        if (context.Metadata.ModelType.GetTypeInfo() == typeof(ODataQueryOptions) ||
            context.Metadata.ModelType.GetTypeInfo().IsSubclassOf<ODataQueryOptions>())
        {
            return new ODataQueryOptionsModelBinder();
        }

        return null;
    }
}

and finally register it in the ConfigureServices method

var mvc = services.AddMvc(options =>{
	options.ModelBinderProviders.Insert(0, new ODataModelBinderProvider());
});

This version is a complete rewrite of the User Interface to make it more appealing and easier to add functionalities to.

Also it comes with some new features:

• the agent no longer stops if multiple packages are found when updating
• application groups can be reordered in homepage customizing the placement for every user
• an application enviroment configuration can be cloned from another enviroment
• an entire application configuration can be cloned from another one

Stay tuned for more features.

With the beta 8 of ASP.NET 5 a new deploy option is available that lets you deploy your website to a virtual machine in Azure running Docker. This is actually pretty simple and well covered by the documentation but what if you don’t have an Azure Account, network access or simply prefer to try things on your local computer.

This situation is not covered by the docs so I’ll cover the necessary steps. Note that I’ve tried this instructions on Windows 10 but there should be no problem on WIndows 7, 8 or 8.1 .

Prerequisites

First of all make sure you’ve installed all of the followings:

• docker machine
• Visual Studio 2015 (at least community edition)
• Microsoft ASP.NET and Web Tools 2015 (Beta8)
• Visual Studio 2015 Tools for Docker - October Preview

and verify your docker installation is working.

Deploying to Docker

The first thing to do is to create a new ASP.NET Web Application with the ASP.NET Preview Templates. Choose Web application as in the image and uncheck the host in the cloud option.

Proceed with project creation and then build it by pressing Ctrl+Shift+B. To start the deploy simply right-click on the project and select the Publish option.

Choose the docker containers option and then the Custom Docker host.

Now you will have to specify the connection info for your local Docker host

To obtain these info launch the Docker quickstart terminal installed with the Docker Tools.

You will see, drawn in green, the name of your machine and it’s IP, in this case 192.168.99.100. Return to the connection info dialog and insert ** tcp://192.168.99.100:2376 **. Then execute in the terminal

docker-machine config default

substituting default with your machine name. You will see all the config options o connect to your docker host. Copy all of it except the last parameter ( -H tcp://192.168.99.100:2376) as it is not necessary and paste it in the **Docker Advanced Options > Auth Options ** field.

Now you’re done. Press Publish and wait until the build terminates, the browser will automatically open your website running in Docker.

I want to select all the element in the table and [print|delete|close|whatever] them

While this request is reasonable (sometimes) it carries a lot of problems that must be solved to implement it correctly:

• how many elements can be selected together ? 10, 20, 50, a thousand?
• how many users the system has that can use this feature together
• does the user have to see the status of his pending jobs?

This type of feature can easily cause problems if not tought well. Imagine a user coming in, selecting a thousand rows and clicking “Print”. Now the system has to print maybe a couple thousand pages which may take some time.

If the action can be completed in a small time usually there is no problem but imagine a user that gives the command and doesn’t receive a timely response. Usually one of the thing he tries is to execute the action again which means your system is now printing double the pages.

This problem can be even compounded if many users try to use the same function swamping your application with pending requests until it grinds to a halt, especially if these jobs are processed by a queue that cannot be emptied sufficiently fast.

In some of this cases you’ll find that a really simple solution can be used that can be simply called “cheating”. Suppose you have the list of elements to process and for each of these you have to make a AJAX call to the server. Instead of creating a new action to process all the element in a batch you can simply chain all the request together to execute in sequence and show an update on screen in this way:

var d = jQuery.Deferred();
var p = d.promise();
var i = 0;
for (i = 0; i < chosen.length; i++) {
  p = p.then(_.bind(function (index) {
    return $.post("youaction", function (response) {
	  "SHOW AN UPDATE ON SCREEN"
    });
   },this, i))
}

d.resolve();

As you can see all we do is create an initial promise through jQuery and then proceed to concatenate a Promise for each element to process. The last line simply starts the process by resolving the first request and the starting with the second and so on.

While I called this solution “cheating” as it doesn’t really process in batch all the element it has some nice properties:

• it solves the user problem fully as it allows him to select some elements and apply an action to them in bulk
• it doesn’t swamp the system with huge requests, as only one element at a time is processed
• it eliminates the problem of having to stop the user from requeing the same batch because he thinks it is taking too much, or from having to implement a way to show the user the status of his pending jobs.

All in all a simple solution that pleases almost everyone. The only drawback is that if the user closes the browser not all the elements will be processed but in many cases you’ll find that this doessn’t matter.

This is not a big problem if you extension doesn’t target specific capabilities introduced only in the latest versions as every Visual Studio versions install the preceding versions libraries.

Sometimes, when you upgrade your extensions to target the new visual studio versions, you receive a complaint from someone that your extensions doesn’t work anymore. Further this seems to happen only if you have only an old VS version (usually only 2012) installed so you’re left to ponder what happened.

Searching on the internet for the specific message you find the likely cause, using newer versions of visual studio updated your project references to target the new dll versions which can’t be found in a system that only has vs 2012 installed.

A better search finds many results here, here and here suggesting some options :

• creating two separate extensions to target VS2012 and VS2013
• load dynamically the required library
• manually edit you csproj to remove the new reference and pay attention to the fact that VS will always try to update them

Solution 1 is a no-go as I’m lazy and for a simple extension like Gruntlauncher I don’t want to mantain two separate version. Option 2 is doable but a little complex while solution 3 is the easiest but feels a lot like battling with Visual studio.

Luckily I found another options in the form of the VSSDK nuget pakages. These packages when installed allow you to always reference the correct version of the library without having to mantain separate version or resort tu ugly hacks.

Having updated TFS to the 2013 version I’ve found there’s an easier way to do it by leveraging it’s ability to execute a Powershell script during the build. This can be done easily:

• install grunt/gulp globally on every build agent. Pay attention to the fact that it must be installed as the user that runs the build agent and the grunt/gulp location must be included in the PATH variable (else you won’t be able to invoke grunt/gulp).

• Add a powershell script inside your solution with the following lines

    Push-Location "$PSScriptRoot\..\Source\Web"  
    Write-Host "npm package restore"
    & "npm" install
    if ($LastExitCode -ne 0) {
      Write-Error "Npm package restore failed";
      exit 1;
    }
  
    Write-Host "Grunt requirejs"
    & "grunt" requirejs
    if ($LastExitCode -ne 0) {
      Write-Error "Grunt requirejs failed";
      exit 1;
    }
    Pop-Location
  

• Modify your build definition to include the script by going in the process Tab -> Build section -> Advanced -> PreBuild script path
• Run your newly configured build and enjoy.

The script it’s really simple but sometimes must be adapted to your configuration and can be easily extended. The first line moves the current working directory to the directory containing you package.json file and then executes an npm install to restore all the needed node packages. After that it exeutes grunt requirejs and finalyy restores the original working directory.

This step can be easily replaced by running gulp or extended by compiling your sass etcetera… .

To be able to do this I didn’t have many options so I used an hack: executing the file in a javascript engine and reading the option object to identify the tasks.

While this works it has many unhandled corner cases:

• all the grunt utility functions must be present and defined
• all the gulp utility functions must be present and defined
• all the common node functions should be present and defined ( this is almost impossible to do as they are too many)

While this was an hack it worked quite well with just an handful of unhandled cases but everytime someone had a problem I got back to thinking to a better and more robust solution.

Then an idea dawned on me: Why should I mock all these functions and not simply ask to grunt and gulp for the defined config options? While this seems easy to do you have to remember that I cannot simply invoke the command line and look at the results as I need the whole options object for postprocessing and also because it’s not a perfect solution.

WIth some experiments I came to the following node.js code for gulp:

var gulp = require('gulp');
require('./gulpfile');
console.log(Object.keys(gulp.tasks).join(' '));

and a similar snippet for grunt (in this case I also look for subtasks)

var param = grunt.config.data;
var names = [];
for(var prop in param){
	if(param.hasOwnProperty(prop)){
		names.push(prop);
		if(param[prop] === Object(param[prop])){
		    var arr=[];
			for(var innerProp in param[prop]){
				if(param[prop].hasOwnProperty(innerProp)){
					if(innerProp!=='options'){
						arr.push(prop+":"+innerProp);
					}
				}
			}
			if(arr.length > 1){
				for (var i=0;i< arr.length;i++){
					names.push(arr[i]);
				}
			}
		}
	}
}

With these I can let gulp and grunt do the work, trusting the files to be well formed and the necessary plugins installed, then simply invoke this code from .NET thanks to Edge.js.

GruntLauncher is gonna get a serious refactoring..

As it always happens some of these options were of the type enable/disable behaviour which can be modelled with a simple checkbox.

While the checkbox works I felt the need for a more stylish solution and decided to try to replicate in CSS the Windows 8 checkbox.

First thing I searched the internet looking for a ready solution and found something close to what I wanted in Metro UI, which has a checkbox with the correct style but with a major defect: when clicked the checkbox switches state immediately ruining the overall effecct.

Solving this problem was quite easy and it took only the addition of a css animation on the slider movement and the slider color change.

The result and also the modified CSS code cand be seen here:

See the Pen bszrE by Paolo Nicodemo (@paonic) on CodePen.

Two things in this example are interesting to note:

• an additional span is required to style everything correctly as some browsers don’t support the :after pseudoselector on an input field (Firefox if I remember correctly)
• the animated transition is set not only on the span position but also on the original span so even the background color is animated thus giving a much more natural effect

You know the situation: a button is clicked, a call is made to the server to create a new order and after the call finishes the form closes. In my case if you were fast enough you could click a couple of times on the button before the call finished, resulting in multiple calls and multiple orders.

To solve this problem once and for all I decided to try my hand at creating a custom directive. Looking in Angular the source code I searched for the ng-click directive and modified it to create ng-single-click.

This directive can be used by simply substituting ng-click with ng-single-click. If the invoked expression returns something similar to a Promise (meaning it has a finally function) it will automatically ignore all the clicks on the element between the start of the promise and its fulfillment or rejection.

PS: After some tests I noticed that stopping clicks without giving the user a hint that work is currently being done is not a good user experience so I created a second version of this directive that adapts ladda-button to show a working animation in the clicked button.

This new version brings three new features:

• the ability to launch commands in the same directory as your gruntfile. Some people complained (rightly) that the commands were always executed at the project root and this was not always right because the gruntfile sat in a subfolder.
• support for grunt targets. Now if you have a task with at least two targets all will be shown as options to invoke directly. If there’s only one target only the task will be shown.
• npm install support thanks to Mads Kristensen. Now when right clicking on you package.json file you will see the option to install all the specified packages (npm install).

As a news the next version of GruntLauncher will almost certainly get a rename as the current name doesn’t reflect anymore the features it has.

This new release brings a lot of improvements:

• better gruntfile parsing support

• use of a submenu to group all grunt commands, useful when your gruntfile has many entries ( thanks to Mads Kristensen who did all the work )

• support for executing bower update on all your packages or on a specific package when right-clicking on it ( again thanks to Mads Kristensen )

• support for gulpfile parsing in the same way it is done with gruntfiles (I’ve began to use gulp and support for it was easy to add )

With these new functionalities I believe I will have to change the plugin name to something more significant but it will take me some time to come up with a decent name.

The ability to have a simple, unique and repeatable process allows you to build and deploy your project without manual intervention.

Howewer it can be tricky to customize the build templates used by TFS to include specific additional steps like invoking grunt and executing additional tasks. For this reason I created a nuget package Grunt.MsBuild that can help you to integrate grunt execution in your TFS build by simply installing it in your projects.

What does it do

The Grunt.MsBuild package extends your build with a new target that sequentially invokes

• npm install ( to install all the needed packages and dependencies )
• grunt build$Configuration (where $Configuration will be replaced by the current build configuration allowing you to customize the build process when in debug mdoe or release mode)

Version Differences

To address all the possibilities I’ve created two different packages:

• The local version assumes grunt-cli is installed as a local module and will use it to launch grunt
• the global version assumes grunt-cli is installed globally and available in your path

This separation was necessary because while it’s easy to install grunt-cli globally on your development machine it could not be possible on the build server.

Running it

I’ve used successfully the packages on a on-premise version of tfs but if you want to use it on VisualStudioOnline it’s currently not possible because it still uses node 0.6 which is not supported by grunt.

There are to solutions to this problem:

• wait until node is updated on the build servers
• commit the node modules you depend on in TFS ( I don’t recommend this solution as it can cause problems with the number of files to save)

Where can I get it

You can download it from the Github repository or install them trough Nuget

What’s new

This version brings two improvements:

1. execution of grunt tasks is no more blocking (this was due to a bug in node for windows but newer version have solved it so make sure to have a recent version installed, for example 0.10.22)
2. long running tasks like grunt watch can be started and run in background, writing the output in the output pane. The command status will become checked and clicking again on it will stop the process