Colorizing output from msbuild in strider

Now that I have nuget restoring my projects packages in strider at build time, I wanted to get msbuild's output colorized. I was hoping that it would have an option to force color on, but unfortunately it does not. What I found odd is that you can force it off. W.T.F. I get that by default you don't want to be sending ANSI color codes to a log file, but why not give both options for controlling color on the console? Thankfully, msbuild supports custom loggers. So, at least there is that. It is annoying that I have to try to duplicate the default logger, but at least it is possible.

Instead of adding the logger to strider-dot-net, I decided to add a new package: strider-msbuild-logger. This enabled me to make it an optional dependency for strider-dot-net. This is important because during an npm install, the logger is going to have to be compiled. I didn't want strider-dot-net to fail to install if for some reason the colorized logger couldn't be built. The other thing that this new package does is give you the path to the logger. If it is null, or undefined, you can safely assume that the logger doesn't exist.

The javascript for the logger's index.js is very simple:

var fs = require('fs')  
  , path = require('path');

module.exports = function () {  
  var logger = path.join(__dirname, 'Strider.MsBuild.Logger.dll');
  if (fs.existsSync(logger)) {
    return logger;
  }

  return null;
};

Since it is an optional dependency, the require could fail, so I have to protect the code that uses it with a try/catch block (in strider-dot-net's worker.js):

try {  
  var logger = require('strider-msbuild-logger')();
} catch (err) {
  logger = null;
}

if (logger) {  
  // shut off the standard console logger, otherwise the output will be logged twice
  args.push('/noconsolelogger', '/logger:' + logger);
} 

The actual meat of the logger is pretty boring, as it just implements the ILogger interface. I did finally figure out the ANSI control codes, thanks to wikipedia (of course). What is interesting, is that it doesn't seem to control the output when building manually in a Windows Command Prompt (it displays them as unicode characters). The article specifically states that Windows Command Prompts don't interepret these sequences, so that would explain it.

At the end of the day, I'm pretty happy with how it turned out:

You can grab the code on github.

-AH