It turns out that you can specify a command line to run as an action. The difference is that instead of allowing node-gyp to create the visual studio project to build (and building it), you just have to specify a command line that will do the build. If using a .csproj file, this is how you'd do so:

{
  'targets': [{
    'target_name': 'my-project',
    'type': 'none',
    'actions': [{
      'action_name': 'compile',
      'inputs': [ 'all.cs', 'your.cs', 'files.cs' ],
      'outputs': [ 'path\to\result.dll' ],
      'message': 'msbuild myproject.csproj',
      'action': ['msbuild', 'myproject.csproj', '/p:Configuration=Release']
    }]
  }]
}

A couple of notes:

• inputs and outputs must be specified, or node-gyp won't run your action during a build
• inputs can be a blank array, but outputs must have at least one item, or node-gyp won't build it.
• The project specified as the argument to msbuild will specify where to output the file, so outputs doesn't really matter.
• Likewise, the project file specifies the files to build, so the contents of inputs isn't important.
• outputs can be useful for other actions that wouldn't build your directory structure for you, as node-gyp will create it.
• If your code exists in 1 file, consider calling csc (csharp compiler); you won't need a project file.

For my project, here is the resultant binding.gyp:

{
  'targets': [{
    'target_name': 'strider-msbuild-logger',
    'type': 'none',
    'actions': [{
      'action_name': 'compile',
      'inputs': [ ],
      'outputs': [ 'strider.msbuild.logger.dll' ],
      'message': 'msbuild Strider.MsBuild.Logger.csproj',
      'action': ['msbuild', 'Strider.MsBuild.Logger.csproj', '/nologo', '/tv:2.0', '/p:Configuration=Release']
    }]
  }]
}

I'm not using csc here, because I want to force the use of .NET 2.0. That way, all versions of msbuild can use my logger. As far as I'm aware, there is no way to force csc to do so.

I hope this quick tip is enough to get you started. There are more advanced scenarios, such as conditional actions (which would be great for building on linux with mono [in fact, edge does this]).

If you want to see how my project is using this, you can check it out on github.

-AH

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

Thankfully, http://nuget.org hosts the latest version of nuget.exe at http://www.nuget.org/nuget.exe. This makes it extremely easy to pull down the latest version. I used request to pull it down, as it is easy to download a file:

request.get('http://www.nuget.org/nuget.exe').pipe(file);  

I decided to store nuget.exe in strider's base directory (c:\.strider on my dev box), as strider is guaranteed to be able to write there. It is pretty easy to get inside a runner context:

var nugetPath = path.join(context.baseDir, 'nuget', 'nuget.exe');  

I then used fs-extra to make sure the full path to the file exists for writing, and then download it:

fs.ensureFile(nugetPath, function() {  
  var file = fs.createWriteStream(nugetPath);
  request.get('http://www.nuget.org/nuget.exe').pipe(file);
});

I also decided to ensure that the latest version of nuget is installed (if nuget.exe already exists):

fs.exists(nugetPath, function(exists) {  
  if (exists) {
    childProc.spawn(nugetPath, [ 'update', '-Self' ]);
  } else { // download it... see above }
});

In order to get the packages, I just had to call nuget restore:

context.cmd({  
  cmd: {
    command: nugetPath,
    args: ['restore', '-NonInteractive' ],
    screen: 'nuget restore'
  }
}, done);

In all these code snippets, I removed all the extraneous logging information. But, in the actual repo, there is a lot of code to give more feedback when building in strider. You can check it out on github.

-AH

The build system for .NET is pretty easy to use. It is all supported in msbuild. The problem is how to determine where it lives. And which version to use (as of now, these versions exist: 1.0, 1.1, 2.0, 3.0, 3.5, 4.0).

My first idea was to use the vcvarsall.bat file, as it will put msbuild in the path. Since it is included in Visual Studio, I was all set to give you a choice of which version of VS to use to run the build. And I didn't want to just execute vcvarsall.bat in the same context that strider was running in, as it would pollute the environment for all jobs. Instead, I used cmd.exe (the /c closes the cmd shell after the command has executed) to execute multiple items at once:

cmd /c '/path/to/vcvarsall.bat' & 'msbuild myproj'  

After getting all that working in strider (it was obviously a lot more complex than that), I realized that Visual Studio should not be installed on a build server. Ideally, it should be as unpolluted as possible, to give more confidence that a user's machine can run your project without additional software (besides the appropriate version of .NET).

Since msbuild is included with the framework, I was able to call it from the .NET installation directory. Which is: %WINDIR%\Microsoft.NET\Framework\{version} or %WINDIR%\Microsoft.NET\Framework64\{version} for 64 bit msbuild. Generally, this will be c:\windows, but using the environment variable is obviously safer than assuming windows is installed to the default directory and drive.

So, now I have a selection box that lets the user pick the version of .NET, and the build step will try to detect if msbuild exists in the given directory. Right now, it favors the 64 bit framework, but I am not entirely sure if that is correct, or if it even matters. For all I know, they are identical programs.

I used async's waterfall method, so I don't need a ton of nested function calls in the code that detects msbuild:

function findmsbuild(version, framework, callback) {  
  var root = process.env.windir + '\\Microsoft.NET\\' + framework;
  async.waterfall([
    function (next) {
      fs.readdir(root, next);
    },
    function (files, next) {
      var dir = _.find(files, function(f) {
        return f.indexOf('v' + version) >= 0;
      });

      if (dir) {
        next(null, root + '\\' + dir);
      } else {
        next('msbuild could not be found for .NET ' + version);
      }
    },
    function (dir, next) {
      var msbuild = dir + '\\msbuild.exe';
      fs.exists(msbuild, function(exists) {
        if (exists) {
          next(null, msbuild);
        } else {
          next('msbuild could not be found for .NET ' + version);
        }
      });      
    }
  ], callback);
}

Then, when I want to call msbuild:

if (config.netVersion && config.netVersion != 'whatever') {  
  findmsbuild(config.netVersion, 'Framework64', function (err, fullpath) {
    if (err || !fullpath) {
      findmsbuild(config.netVersion, 'Framework', function (err, fullpath) {
        if (err) {
          done(err);
        } else {
          msbuild(context, fullpath, args, screen, done);
        }
      });
    } else {
      msbuild(context, fullpath, args, screen, done);
    }
  });
} else {
  msbuild(context, 'msbuild', args, screen, done);
}

Where the msbuild function is:

function msbuild(context, path, args, screen, done) {  
  context.cmd({
    cmd: {
      command: path,
      args: args,
      screen: screen
    }
  }, done);
}

The error in strider when msbuild couldn't be found was pretty bad, so I decided to fix it. The context supports multiple output methods, but there doesn't seem to be any documentation about it. So, I cracked open strider-runner-core to see how to do so. It seems that the status method formats all the output based on the keyword passed as the first argument.

To print the command after the $ sign, I had to pass command.start:

var time = new Date();  
context.status('command.start', { command: screen, started: time, time: time, plugin: 'dotnet' });  

The error had to be passed with stderr:

context.status('stderr', err);  

And, I learned I could colorize it by using ANSI control codes. I don't really get how this works; I just ripped it from strider-runner-core:

context.status('stderr', '\u001b[31;1m' + err + '\u001b[0m');  

And if I didn't pass command.done, the execution timer never stopped:

context.status('command.done', { exitCode: 404, time: time, elapsed: 0 });  

I'm faking the exit code to be 404, because it isn't found. Makes sense, right?

All in all, I'm pretty happy with how easy this was to get setup. With the way strider manages projects, I think the next step is to add the ability to restore nuget packages automatically. I know you can setup nuget package restore to do this, but I think it is silly to store nuget.exe for every project you are going to create.

I have pushed the code to github at abe545/strider-dot-net.

For a Node project, the first thing that strider does is try to get a package.json file from the repo. Unfortunately, there is no good way to do this with either git or mercurial. And of course, there is no codeplex api to do so. Thankfully, strider allows us to specify that we don't support individual files via fastFile. We will also throw an error if getFile is called(in webapp.js):

fastFile: false,  
getFile: function (filename, ref, account, config, project, done) {  
  done(new Error('not implemented'));
}

Next, in worker.js, we need to implement two exports: init and fetch. Based on strider-github, init needs to return an object that also calls fetch, like so:

module.exports = {  
  init: function (dirs, account, config, job, done) {
    return done(null, {
      config: config,
      account: account,
      fetch: function (context, done) {
        module.exports.fetch(dirs.data, account, config, job, context, done);
      }
    });
  }
}

Implementing fetch should be pretty simple. I just need to use strider-git to fetch a git repo, and strider-hg (crap, when I started this series, I thought it existed, but now I can't find it...) hg for mercurial ones:

fetch: function(dest, account, config, job, context, done) {  
  if (config.type === 'git') {
    git.fetch(dest, config, job, context, done);      
  } else if (config.sourceType === 'mercurial') {
    hg.clone(config.sourceUrl, dest, {"-b": job.ref.branch}, done);
  }
}

Now, when I try to test... nothing. Well, crap. After some debugging, it turns out that Codeplex capitalizes git and mercurial. That is annoying, so I decided to alter the parseRepo function in webapp.js to make the sourceType lowercase:

function parseRepo(account, repo) {  
  return {
    id: account.name + '/' + repo.Name,
    name: account.name + '/' + repo.Name,
    display_name: repo.Title,
    display_url: repo.Url,
    group: repo.Role,
    'private': !repo.IsPublished,
    config: {
      sourceType: repo.SourceControl.ServerType.toLowerCase(),
      sourceUrl: repo.SourceControl.Url,
      repoName: repo.Name
    }
  }
}

Trying it again... And it fails. Because the config is missing an auth:

    config: {
      sourceType: repo.SourceControl.ServerType.toLowerCase(),
      sourceUrl: repo.SourceControl.Url,
      repoName: repo.Name,
      auth: {
        type: 'https'
      }
    }

Aaaand... Fail. No repo. Grrr. At this point, I just renamed everything to match the strider-github setup:

    config: {
      type: repo.SourceControl.ServerType.toLowerCase(),
      url: repo.SourceControl.Url,
      repo: repo.Name,
      auth: {
        type: 'https'
      }
    }

I obviously had to change the references everywhere else, also. After doing so, it worked! Well, for git repos anyway. Mercurial repos have an issue with the default branch. In git, it is master, where in mercurial it is default. Strider doesn't take this into account, so I had to:

var branch = job.ref.branch;  
if (branch === 'master') {  
  // hg's default branch is default, not master... Ideally this would be handled in the repo setup, but use this as a workaround
  branch = 'default';
}

One last problem for the mercurial side of things: it won't report progress to the strider output window. To solve this, I had to do a bit of extra work:

if (config.type === 'mercurial') {  
  var branch = job.ref.branch;
  if (branch === 'master') {
    // hg's default branch is default, not master... Ideally this would be handled in the repo setup, but use this as a workaround
    branch = 'default';
  }
  var start = new Date()
    , cmd = 'hg clone ' + config.url + ' . -b ' + branch;
  context.status('command.start', { command: cmd, time: start, plugin: context.plugin });
  hg.clone(config.url, dest, {"-b": branch}, function(err, output) {
    var end = new Date()
      , elapsed = end.getTime() - start.getTime();
    if (err) {
      context.out('hg error: ' + err.message);
    }

    if (output) {
      output.forEach(function(line) {
        context.out(line.body);
    });
  }

  context.status('command.done', {exitCode: 0, time: end, elapsed: elapsed});
    done(err, output);
  });
}

And with that, Strider can fetch code from Codeplex!

One last thing I've done, to make the plugin match the other strider plugins: I moved strider.json to package.json.

You can grab the code at github.

-Ah

Unfortunately, the Codeplex API doesn't include any functionality for getting the branches for a given repository. This means I am going to have to do this work manually, and I'm going to have to go through the source control provider.

For Mercurial branches, I thought it would be somewhat of a rigamorale. You see, Mercurial requires the repository to be on a local computer before you can see the branches. It turns out, stackoverflow has a question (and answer!) about how to query a remote repository. Since Codeplex uses hgweb to serve the repo, we can query it directly:

if (sourceType === 'mercurial') {  
    request(config.sourceUrl + '/branches?style=raw', function(error, response, body) {
        if (error) return callback(error, null);
        var branches = [];
        var rows = rawText.split(/\r\n|\r|\n/g);

        // ignore the last row... it is always blank
        for (var i = rows.length - 2; i >= 0; i--) {
            var branchInfo = rows[i].split(/\t/g);
            if (branchInfo[2] !== 'closed') {
                branches.push(branchInfo[0]);
            }
        }

        callback(null, branches);
    });
}

Mercurial branches can be marked closed, but they are never deleted. Since Codeplex returns all Mercurial branches, I must filter out the closed ones.

For git repositories, my first thought was to use strider-git. Unfortunately, it requires a context object, but the context is only available when jobs are being run. Since the branch retrieval is happening long before that, I decided to use git-node. It is almost as easy to use as the mercurial setup:

if (sourceType === 'git') {  
    var remote = git.remote(config.sourceUrl);
    remote.discover(function(err, refs) {
        if (err) {
            callback(err, null);
        } else {
            remote.close(function(error) {
                if (error) {
                    callback(error, null);
                } else if (!refs) {
                    callback("No data returned for the repo.", null);
                } else {
                    var branches = Object.keys(refs).filter(function (ref) { return ref.indexOf('refs/heads/') == 0; }).map(function (ref) {
                        return ref.replace('refs/heads/', '');
                    });

                    callback(null, branches);
                }
            });
        }
    });
}

I don't want to get anything but branches, hence the filter. If I wanted to use tags, removing this filter will allow me to do so.

Now when I go to the configure screen, it navigates correctly, but the UI seems... off. It appears that I have missed something... Oh yes, the config.html and config.js. I haven't implemented anything to configure, but after throwing (basically) blank config files at strider, things seem to be working fine:

<div class="row-fluid">  
</div>  

app.controller('CodeplexController', ['$scope', function ($scope) {  
  $scope.config = $scope.providerConfig();

  $scope.save = function () {
    $scope.providerConfig($scope.config, function () {});
  };
}]);

And with that, I can successfully add projects to strider, open the config screen, and you can get autocomplete in the branch selection box! Woot! Maybe I can soon have it actually fetching and running tests... maybe. As always, you can grab the code on github.

-AH

First, the codeplex oauth tokens expire after an hour. Because of this, I am seeing a number of authentication errors. In order to solve this, I need to get the refresh token from codeplex. Thankfully, it seems this is a feature built into passport. All I had to do was update the validation methods to take one more parameter:

function validateAuth(req, accessToken, refreshToken, parms, profile, done) {  
  if (!req.user) {
    console.warn('Codeplex OAuth but no logged-in user')
    req.flash('account', "Cannot link a codeplex account if you aren't logged in")
    return done()
  } 
  var account = req.user.account('codeplex', profile.UserName)
  if (account) {
    console.warn("Trying to attach a codeplex account that's already attached...")
    req.flash('account', 'That codeplex account is already linked. <a href='https://codeplex.com/site/signout/'  target="_blank">Sign out of codeplex</a> before you click "Add Account".')
    return done(null, req.user)
  }

  req.user.accounts.push(makeAccount(accessToken, refreshToken, profile))
  req.user.save(function (err) {
    done(err, req.user);
  })
}

function makeAccount(accessToken, refreshToken, profile) {  
  var username = profile.UserName;
  return {
    provider: 'codeplex',
    id: username,
    display_url: 'https://www.codeplex.com/site/users/view/' + username,
    title: username,
    config: {
      accessToken: accessToken,
      refreshToken: refreshToken,
      name: username,
      avatar: profile.Avatar
    }
  }
}

With the refresh token on hand, I was able to use the refresh-token package to get a valid oauth token. The way I see it, there are 3 options for handling token refreshes:

• Always get a fresh token before making an API call
• Store the expiration of the token, and only refresh when needed
• Assume a valid token; on error, refresh and retry

I am unsure if there is a best practice for this, but I decided on option 3. The first option seemed like too much overhead for my taste. The second option is appealing to me, but I was too lazy to go look up how to translate the token's expiration timeout into an absolute expiration date. Horrible, I know. But, there you have it. I went with #3 because lazy.

Now that I might have to refresh the token, my API method will need the clientId and clientSecret. I modified getCodeplex and getRepos to take the appConfig, as both are properties there. The most important bit, getCodeplex:

function getCodeplex(account, appConfig, resourcePath, callback) {

    var options = {
      hostname: 'www.codeplex.com',
      path: resourcePath,
      method: 'GET',
      headers: {'x-ms-version': '2012-09-01' }
    };

    if (account && account.accessToken) {
        options.headers.Authorization = 'Bearer ' + account.accessToken;
    }

    var req = https.request(options, function(res) {
        var json = '';
        res.on('data', function(d) {
            json += d;
        });
        res.on('error', function(err) {
            callback(err, null);
        });
        res.on('end', function() {
            var fin = JSON.parse(json);

            // this is an error message
            if (fin.Message) {
                if (appConfig.clientId && appConfig.clientSecret && fin.Message === 'Authentication required.') {
                    var tokenProvider = new TokenProvider('https://www.codeplex.com/oauth/token', {
                    refresh_token: account.refreshToken, 
                    client_id:     appConfig.clientId, 
                    client_secret: appConfig.clientSecret
                    });

                    tokenProvider.getToken(function (err, token) {
                        if (err) { callback(err, null); }
                        else {
                            account.accessToken = token;
                            getCodeplex(account, resourcePath, callback);
                        }
                    });
                }
                else {
                    callback(fin.Message, null); 
                }
            }
            else { callback(null, fin); }
        });
    });

    req.on('error', function(err) {
        callback(err, null);
    });
    req.end();
}

The second bug: when I try to add a repo to strider, I get an error message in the UI:

Error creating project for repo aheidebrecht/codeonlystoredprocedures:  
{
  "results": [], 
  "status": "error", 
  "errors": [ { 
    "code": 400, 
    "reason": "provider.repo_id is required" 
  } ]
}

It seems that I left out a required id property in the parseRepo method:

function parseRepo(account, repo) {  
  return {
    id: account.name + '/' + repo.Name,
    name: account.name + '/' + repo.Name,
    display_name: repo.Title,
    display_url: repo.Url,
    group: account.name,
    'private': !repo.IsPublished,
    config: {
      sourceType: repo.SourceControl.ServerType,
      sourceUrl: repo.SourceControl.Url,
      role: repo.Role
    }
  }
}

After fixing these issues, I was finally able to start the process of setting up a repo. I decided to hold off on implementing the webhook part mostly because, as of this blog post, there is no generic webhook support (it supports these and these commercial websites... oh Microsoft).

Instead, I just let strider think I have done something special. Since I don't have to setup or teardown a webhook, those two required api methods are quite simple:

setupRepo: function (account, config, project, done) {  
  if (!account.accessToken) return done(new Error('Codeplex account not configured'));
  done(null, config);
},

teardownRepo: function (account, config, project, done) {  
  if (!account.accessToken) return done(new Error('Codeplex account not configured'));
  done(null, config);
}

With those methods in place, we can add and remove a repo to strider! Woot!

You can grab this version at github.

-AH

Over at the project page for the strider extensions loader, there is some documentation about creating a plugin. They have some clearly defined roles, one of which is provider. For source control providers. You know, like codeplex. Based on this documentation, I created the following project structure:

codeplex-for-strider
|
+-config
: |
: +-config.html
: +-config.js
|
+-lib
: |
: +-codeplex.js
|
+-webapp.js
+-worker.js
+-package.json
+-strider.json

I just created blank files for all the new items. Following along with the readme, I configured my strider.json thusly:

{
  "id": "codeplex",
  "title": "Codeplex",
  "type": "provider",
  "hosted": true,
  "config": {
    "controller": "CodeplexController"
  },
  "accountConfig": {
    "setupLink": "/ext/codeplex/oauth"
  },
  "webapp": "webapp.js",
  "worker": "worker.js",
  "inline_icon": "windows"
}

I don't know if it is a documentation issue, or if there are two ways of specifying the url to call to start the authorization process. The docs say to export setupLink, but both the strider-github and strider-bitbucket plugins specify it in the strider config (in their package.json). Since I trust code more than documentation, I too put it in the config.

The plugin obviously doesn't yet do anything, but after dropping this folder in strider's node_modules directory, I saw it show up in strider! I didn't even have to put it in the package.json. This makes it incredibly easy to test.

Because I'm a sadist masochist, my first instinct was to click the Setup Codeplex button. I knew it would fail, but I was curious to see how explosively. It (pleasantly) surprisingly didn't crash the node process, but instead I got:

500  
Error: no strategy registered under name: codeplex  

And looking at the stack trace (that is niiiiiiiceeeeee) I can see that the strategy is related to something called passport. I was really hoping that somebody had already done the work of creating a codeplex strategy for me, but alas, no such luck. It turns out you can use the passport-ouath2 strategy directly, but since codeplex recommends passing the api version as a header, I decided to create my own.

Thankfully, this is really easy. I looked at a number of examples, and I came to the conclusion that this is pretty much boilerplate code. As such, I won't include it here. I will likely break it out into its own project at some point in the near future, even if it doesn't have a lot going on.

So, with a codeplex passport strategy working, I was able to add the auth export in webapp.js:

var codeplex = require('./lib/codeplex')  
  , CodeplexStrategy = require('./lib/passport-codeplex');

module.exports = {  
  auth: function (passport, context) {
    var config = this.appConfig
    passport.use(new CodeplexStrategy({
      clientID: this.appConfig.clientId,
      clientSecret: this.appConfig.clientSecret,
      callbackURL: this.appConfig.hostname + '/ext/codeplex/oauth/callback',
      passReqToCallback: true
    }, validateAuth));
  }  
  ...
}

I also had to configure an oauth application at codeplex. After doing so, I had to add the information into the webapp.js:

module.exports = {  
  appConfig: {
    hostname: 'http://localhost:3000',
    clientId: 'feecb876f9044bca8a86ab9089fba8b0',
    clientSecret: 'efc1e8c120c24b59b12ad0f4f7d32d02'
  }
  ...
}

Thoe credentials are for a test application I created that will connect to the default strider DEV settings (localhost:3000). When this plugin gets put into production, I will obviously be using a different set of credentials.

The last step is to create the callback (validateAuth in the auth export) that will register the account in strider. I shamelessly copied most of this from the strider-bitbucket plugin, but modified it slightly to parse the data returned from codeplex:

function validateAuth(req, accessToken, parms, profile, done) {  
  if (!req.user) {
    console.warn('Codeplex OAuth but no logged-in user')
    req.flash('account', "Cannot link a codeplex account if you aren't logged in")
    return done()
  } 
  var account = req.user.account('codeplex', profile.UserName)
  if (account) {
    console.warn("Trying to attach a codeplex account that's already attached...")
    req.flash('account', 'That codeplex account is already linked. <a href='https://codeplex.com/site/signout/'  target="_blank">Sign out of codeplex</a> before you click "Add Account".')
    return done(null, req.user)
  }

  req.user.accounts.push(makeAccount(accessToken, profile))
  req.user.save(function (err) {
    done(err, req.user);
  })
}

function makeAccount(accessToken, profile) {  
  var username = profile.UserName;
  return {
    provider: 'codeplex',
    id: username,
    display_url: 'https://www.codeplex.com/site/users/view/' + username,
    title: username,
    config: {
      accessToken: accessToken,
      name: username,
      avatar: profile.Avatar
    }
  }
}

After that, I clicked on the setup codeplex account button again, and I got directed to codeplex! I get really excited for things like this; sad, I know. Upon authorizing the application... node crashed. We need a listRepos export. Well, we have a function that does this... let's call it!

listRepos: function (account, callback) {  
  codeplex.getRepos(account, callback);
}

Oh, wait, that account object isn't just a username anymore. We need to update the getRepos function to use the account class. Also, now that we are authorized, we should pass the token instead of the username. I am a little embarrassed by how long it took me (seriously about 5 hours of googling, and I never really found a helpful answer with my searches...) to figure out how to pass the token, but I have never really done web programming before. So, I guess I should feel better. Maybe.

Anyway, you can pass it as the Authorization header. So, my updated getRepos looks like this:

function getRepos(account, callback) {

    var options = {
      hostname: 'www.codeplex.com',
      path: '/api/user/projects',
      method: 'GET',
      headers: {'x-ms-version': '2012-09-01' }
    };

    if (account && account.accessToken) {
        options.headers.Authorization = 'Bearer ' + account.accessToken;
    }

    var req = https.request(options, function(res) {
        var json = '';
        res.on('data', function(d) {
            json += d;
        });
        res.on('error', function(err) {
            callback(err, null);
        });
        res.on('end', function() {
            var repos = JSON.parse(json);
            callback(null, repos);
        });
    });

    req.on('error', function(err) {
        callback(err, null);
    });
    req.end()
}

One more try clicking that setup codeplex button... success!

I can now go to my codeplex project tab, and I see 2 entries, but they are both blank. Looks like I need to massage the data a little bit. I could do it all in the getRepos method, but eventually I am going to need to make other api calls, and will probably want to use the same helper method for doing so (getRepos is going to become getCodeplex). Keeping this in mind, I created a parseRepo function in webapp.js:

function parseRepo(account, repo) {  
  return {
    name: account.name + '/' + repo.Name,
    display_name: repo.Title,
    display_url: repo.Url,
    group: repo.Role,
    'private': !repo.IsPublished,
    config: {
      sourceType: repo.SourceControl.ServerType,
      sourceUrl: repo.SourceControl.Url
    }
  }
}

According to the docs, strider needs 3 values for the config: name, url, and display_url. Because strider expects the name to be of the form <username>/<reponame>, I had to pass the account in addition to the repo. The other properties are undocumented, but I found them being set in the strider-bitbucket source, so I too decided to set them. Because codeplex doesn't send the actual owner of a project, I am grouping them by the user's role on the project (both strider-github and strider-bitbucket use the repo's owner for the group). The config property is user defined, but the docs said to also export a mongoose template named config:

module.exports = {  
  ...
  config: {
    sourceType: String,
    sourceUrl: String
  },
  ...
}

I then modified the listRepos method to call parseRepo for each item (map):

module.exports = {  
  ...
  listRepos: function (account, callback) {
    codeplex.getRepos(account, function(err, data) {
        if (err) return callback(err)
        callback(null, data.map(function(repo) { return parseRepo(account, repo); }))
    });
}

With all that done, I now see all my codeplex repos in strider! You can grab the latest version over at github.

-AH

In order to make it useful, I did a little bit of refactoring. I created a new codeplex.js file, and moved the code that does all the work into it. This will be the place where all calls to codeplex occur. I created a method that takes the user's name as a parameter, and will get their repositories. It also takes a callback function, which by node convention expects two arguments: err and data. Errors will be passed in err, and the results will be passed in data:

function getRepos(user, callback)

Also, after reading about the codeplex api version,

Wait, wait, wait. Seriously Microsoft... you haven't updated the codeplex api in at least 1.5 years?! Have you done any work on it in that time? site in 5 months?! And the last update to the API (to add 3rd party web apps, but no generic webhooks) was 9 months ago?! It is no wonder that github is so much better that even your own teams are using it instead of codeplex. Not that I have a horse in the online code source repository race, but abandonement just seems like a common theme with some of Microsoft's best/most promising/much loved technologies lately.

Anyway, after reading about the codeplex api version, I added the version header to the request options:

var options = {  
  hostname: 'www.codeplex.com',
  path: '/api/users/' + user + '/projects',
  method: 'GET',
  headers: {'x-ms-version': '2012-09-01'}
};

The rest of the code is very similar, but I added functionality to pass along any errors:

var req = https.request(options, function(res) {  
    var json = '';
    res.on('data', function(d) {
        json += d;
    });
    res.on('error', function(err) {
        callback(err, null);
    });
    res.on('end', function() {
        var repos = JSON.parse(json);
        callback(null, repos);
    });
});

req.on('error', function(err) {  
    callback(err, null);
});
req.end();  

The last, and probably most important part was exposing the method as a module. Node's module concept is pretty slick; by exposing it as a module, it makes it really easy to call from other code. Like, really easy (from index.js):

var codeplex = require('./codeplex');

codeplex.getRepos(username, function(err, data) {  
...
});

If you check out the github repo, you'll see I also extended index.js to present a form that you can put in a username to see the codeplex repositories for.

-AH

Now, I have a couple of projects hosted on codeplex, so any continuous deployment solution for me needs to support it as a source control provider. Seeing as strider has support for plugins, my first forray will be creating just such a plugin. I searched the internet for quite a while to try and find a basic node tutorial without much success. Besides how to node, I found a fairly inexpensive e-book that wound up helping a lot.

Okay, for my first trick test, I am just going to try to get the list of repos that I have on codeplex. According to the api docs, this is farily simple. Honestly the biggest snag I ran into was that I was trying to use the http node module to call the api. The docs are clear that you need to use https, but I foolishly did not realize that was a separate module in node. With that much need knowledge, it was pretty darn easy to create a simple server to pull my repos:

var https = require('https');  
var http = require('http');

http.createServer(function(request, response) {  
    console.log("Request handler 'codeplex' was called.");

    var options = {
      hostname: 'www.codeplex.com',
      path: '/api/users/aheidebrecht/projects',
      method: 'GET'
    };

    var req = https.request(options, function(res) {
        var json = '';
        res.on('data', function(d) {
            json += d;
        });

        res.on('end', function() {
            // this is just for display purposes... it is unformatted otherwise
            var str = JSON.stringify(JSON.parse(json), null, "    ");
            response.writeHead(200, { 'Content-Type': 'text/plain' });
            response.write(str);
            response.end();
        });
    });

    req.end();

    req.on('error', function(err) {
        console.error(err);

        response.writeHead(500, { 'Content-Type': 'text/plain' });
        response.write(err);
        response.end();
    });
}).listen(999);

Just running it in node, and I get the expected output:

[
    {
        "Role": "Owner",
        "Name": "wpfprogress",
        "Title": "WPF Background Progress Indicator",
        "Description": "The WPF Background Progress Indicator allows developers to show the application is busy without stopping the animation when the UI thread is busy. The indicator's appearance can be modified by using the BusyStyle property.",
        "Url": "https://wpfprogress.codeplex.com/",
        "IsPublished": true,
        "NumberOfFollowers": 12,
        "SourceControl": {
            "ServerType": "Mercurial",
            "Url": "https://hg.codeplex.com/wpfprogress"
        }
    },
    {
        "Role": "Owner",
        "Name": "codeonlystoredprocedures",
        "Title": "Code Only Stored Procedures",
        "Description": "A library for easily calling Stored Procedures. Works great with Entity Framework Code First models.",
        "Url": "https://codeonlystoredprocedures.codeplex.com/",
        "IsPublished": true,
        "NumberOfFollowers": 2,
        "SourceControl": {
            "ServerType": "Git",
            "Url": "https://git01.codeplex.com/codeonlystoredprocedures"
        }
    }
]

One of the cool things about codeplex is that you can use different source control providers, and you can see that I'm using both git and mercurial. Luckily, strider has support for both. Codeplex also supports TFS, so I may see if I can figure out a way to add that too, but it is low on my radar. As I am planning on turning this thing into a full fledged provider for strider in subsequent posts, I'm going to host it on github.

Here is the changeset at this point in the project.

-AH

• A good internet citizen
• A narcissist
• Both

I have decided to do the good thing and do 302 redirects from the old posts to their new locations.

The first thing I needed to do was point my old blog (blog.abrahamheidebrecht.co) to the new location (gettinggui.com). This was easy to do with my domain registrar, hover.

Sidenote: hover is awesome. Definitely the best registrar I've used. If you haven't looked into them, go there now. Thank me later.

Because my old blog was using wordpress, the permalinks are slightly different from the ghost ones. Thankfully, I wasn't including the date, so it is literally off by one extra word in the path. My wordpress links were of the form /archives/post-slug and the ghost permalinks look are just /post-slug. Now, I am the furthest thing from an expert when it comes to configuring websites, but my spidey sense is telling me this should be easy. It is one word!

Because I am running the new blog on Azure, it is running under IIS (with nodeiis to host ghost). This means I can issue redirects through the web.config file. After a bit of googlefu, I altered my web.config to have two new rules (one is for the old rss feed, which is an even simpler redirect):

<rewrite>  
    <rules>
        <rule name="wp-redirect" stopProcessing="true">
            <match url="archives/(.+)$" />
            <action type="Redirect" url="/{R:1}" redirectType="Permanent" />
        </rule>
        <rule name="wp-rss" stopProcessing="true">
            <match url="feed" />
            <action type="Redirect" url="/rss" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>  

And bam, the old site's links point to my new blog!

-AH

It is my intention to learn node.js, and along the way, I can hopefully contribute some thoughtful words. If not, at least I will learn some much needed new skills.

So, I setup the blog on Azure, which was brain dead simple, but I ran into a few snags that took me way too long to figure out. So, I'll just drop them here in case anybody has the same issues and the googles don't seem to be helping.

First, when deploying the website with git, if you find your blog posts disappearing whenever you do a redeploy, it is because ghost uses sqlite by default. The implications of this are that the database is stored in the filesystem. On your website. Which gets overwritten when you push new source to your azure repository. You can work around this by either deploying via FTP, and only copying over the files that have changed. Or, using FTP, you can pull down the ghost.db file, and check it into your git repo.

Now, because I didn't want to go through that hassle every time I wrote a new post, I decided that maybe sqlite wasn't the best choice for me. Since ghost supports MySQL and PostgreSQL, I figured I could set up a MySQL database on cleardb easily enough. There are many guides on the internet on how to get MySQL working with ghost.

So, I set it up, and as soon as I tried to set my theme to something other than casper... I got an error because there were too many connections open. You see, the free cleardb plan only allows 4 simultaneous connections. And the mysql driver defaults to allowing 10 simultaneous connections. Since it appears that ghost creates a lot of connections to the database in its normal operations, this is a problem.

After much searching of the intertubes, I discovered that you can specify the size of the connection pool used by knex (one of the libraries used to abstract the database storage). You can do so by setting up the maximum pool size in config.js:

database: {  
    client: 'mysql',
    connection: {
        host: 'path-to-cleardb',
        user: 'user',
        password: 'pw',
        database: 'db-name',
        charset: 'utf8'
    },
    pool: {
        max: 4,
        min: 0
    }
}

I thought I was all set, but when I clicked the button to save a draft of the post... I learn I don't have permission to do so. It turns out that when ghost creates the permission tables, it assumes that the id columns will increment by 1. This seems like a normally safe assumption, but in the case of cleardb, they increment by 10 (I assume to allow up to 10 simultaneous inserts to work?).

This was easily fixed by altering the permissions_roles table. Changing the values in permission_id from

| id | role_id | permission_id |
+----+---------+---------------+
|  1 |       1 |             1 |
+----+---------+---------------+
| 11 |       1 |             2 |
+----+---------+---------------+
| 21 |       1 |             3 |
+----+---------+---------------+

to

| id | role_id | permission_id |
+----+---------+---------------+
|  1 |       1 |             1 |
+----+---------+---------------+
| 11 |       1 |            11 |
+----+---------+---------------+
| 21 |       1 |            21 |
+----+---------+---------------+

With that setup, I now have a fully operational battlestation blog.

-AH

My first thought was to just pass a SynchronizationContext into the delegate used to create the Task. I didn’t like that solution because now the idea of the Task as a piece of work is polluted with code simply to make a callback onto the correct thread. Ideally I wouldn’t have to worry about that every time I wanted to report progress from a Task.

The solution I eventually came up with was to use subtasks. When a new Task is created while another Task is being executed, it is added as a child of that Task. These Tasks are aggregated by the parent Task, and can share the same CancellationToken so that if the main Task is cancelled, the child Tasks will also have a cancellation requested. By waiting for the children to complete, the main Task won’t complete successfully unless all the sub tasks have.

In order to make the programming model as similar as possible to standard Tasks, I created a Create method in the ReportableTask static class:

public static class ReportableTask  
{
    public static Task Create<TResult>(Action<Task<TResult>> reportProgress,
        params Func<TResult>[] createWorkTasks)
    {
        if (createWorkTasks == null || createWorkTasks.Length == 0)
            throw new ArgumentNullException("createWorkTasks",
      "Must specify at least one function to create a reportable task with.");

        TaskScheduler current =
            TaskScheduler.FromCurrentSynchronizationContext();
        return new Task(() =>
        {
            List<Task> children = new List<Task>();

            foreach (var func in createWorkTasks)
            {
                Task<TResult> task = new Task<TResult>(o =>
                    {
                        if (AcknowledgePendingCancellations())
                            return default(TResult);

                        TResult res = ((Func<TResult>)o)();

                        if (AcknowledgePendingCancellations())
                            return default(TResult);

                        return res;
                    }, func, TaskCreationOptions.RespectParentCancellation);

                task.ContinueWith(reportProgress,
                    TaskContinuationOptions.OnlyOnRanToCompletion, current);
                task.Start();

                children.Add(task);
            }

            if (!AcknowledgePendingCancellations())
            {
                try
                {
                    Task.WaitAll(children.ToArray(),
                        Task.Current.CancellationToken);
                }
                catch (OperationCanceledException)
                {
                    AcknowledgePendingCancellations();
                }
            }
        });
    }
}

I also created StartNew methods to simplify common Task creation scenarios:

public static Task StartNew<TResult>(Action<Task<TResult>> reportProgress,  
    params Func<TResult>[] createWorkTasks)
{
    Task t = Create<TResult>(reportProgress, createWorkTasks);
    t.Start();
    return t;
}

public static Task StartNew<TResult>(Action<Task<TResult>> reportProgress,  
        Action<Task> continueWith,
        TaskContinuationOptions continueOptions,
        params Func<TResult>[] createWorkTasks)
{
    Task t = Create<TResult>(reportProgress, createWorkTasks);
    t.ContinueWith(continueWith,
            continueOptions,
            TaskScheduler.FromCurrentSynchronizationContext());
    t.Start();
    return t;
}

private static bool AcknowledgePendingCancellations()  
{
    if (Task.Current.IsCancellationRequested)
    {
        Task.Current.AcknowledgeCancellation();
        return true;
    }

    return false;
}

When Cancel() is called on a Task, it sets the IsCancellationRequested property to true, but unless it is acknowledged with AcknowledgeCancellation, the framework will assume that the Task completed successfully when the delegate returns. Creating one of these Tasks couldn’t be easier:

_currentTask = ReportableTask.StartNew<int>(OnProgress,  
                       t => _parent.HasProgress = false,
                       TaskContinuationOptions.OnlyOnRanToCompletion,
                       PerformOperation,
                       PerformLongOperation);

In the sample project I have included, cancellation of the Task is accomplished by clicking on the button that is used to start the Tasks in the first place. You can tell that the Tasks are not completing because when a Task runs to completion, the OnProgress method will add the amount of progress to a list of completed operations to output in an ItemsControl.

The main problem in implementing this as separate sub-tasks is that each sub-task must be atomic. Unfortunately, that is unlikely to be the case when wanting to report progress on some long running operation. The reality is that when we are reporting progress, it is generally to indicate when we have completed a certain aspect of a complex problem that is wholly dependent on the previous work being done.

I’m not sure if there is a better way of doing this using Tasks, but I would love to hear about it if there is.

Here is the source for the post ReportTaskProgress.zip.

-AH

First, I’ll show you how I have traditionally implemented this kind of functionality: Attached Behaviors. This is a concept that has been discussed extensively in the WPF community, so I’ll just show the interesting bits. I’ve created a Zoom static class with a couple of public attached properties: MinimumScale, MaximumScale, EnableMouseWheel. When the EnableMouseWheel property changes, we either attach or detach the PreviewMouseWheel event handler on the UIElement (depending on the new value). Then, when the event is raised, we actually change the RenderTransform of the element to be zoomed:

static void OnEnableMouseWheelChanged(DependencyObject d,  
    DependencyPropertyChangedEventArgs e)  
{
    UIElement elem = d as UIElement;
    if (elem == null)
        throw new NotSupportedException(
            "Can only set the Zoom.EnableMouseWheel attached behavior on a UIElement.");

    if ((bool)e.NewValue)
        elem.PreviewMouseWheel += OnMouseWheel;
    else
        elem.PreviewMouseWheel -= OnMouseWheel;
}

static void OnMouseWheel(object sender, MouseWheelEventArgs e)  
{
    SetZoom(sender as UIElement, e.Delta / 1000.0);
}

private static void SetZoom(UIElement elem, double delta)  
{
    if (GetEnableMouseWheel(elem))
    {
        EnsureRenderTransform(elem);
        ScaleTransform xform = (ScaleTransform)elem.RenderTransform;

        double toSet = (double)elem.GetValue(ScaleFactorProperty);
        elem.SetValue(ScaleFactorProperty, toSet + delta);
        toSet = Math.Pow(Math.E,
            (double)elem.GetValue(ScaleFactorProperty));

        xform.ScaleX =
            xform.ScaleY = toSet;
    }
}

private static void EnsureRenderTransform(UIElement elem)  
{
    if (elem.RenderTransform == null ||
        !(elem.RenderTransform is ScaleTransform))
    {
        elem.RenderTransform = new ScaleTransform(1, 1);
    }
}

I’m using an exponential function to provide a more natural zooming experience. Since zooming out will eventually cause scales < 1, an exponential function causes these changes to appear more linear. Likewise when zooming in very far, a linear function would appear to slow down the rate of zooming.

To use the attached behavior, you would do the following:

<Image Source="flatiron.jpg"  
       RenderTransformOrigin=".5,.5"   
       lcl:Zoom.EnableMouseWheel="True" />

Having just started using Blend 3, I decided to turn this Attached Behavior into a Blend Behavior. This was fairly trivial, and was basically turning the attached properties into regular dependency properties. Also, instead of having an EnableMouseWheel property, I had to override a couple of methods in the behavior:

protected override void OnAttached()  
{
    base.OnAttached();

    AssociatedObject.PreviewMouseWheel += OnMouseWheel;
}

protected override void OnDetaching()  
{
    base.OnDetaching();

    AssociatedObject.PreviewMouseWheel -= OnMouseWheel;
}

The AssociatedObject is strongly typed to be a UIElement, since this Behavior derives from System.Windows.Interactivity.Behavior<UIElement>. This is used in a slightly more verbose way in XAML, but it is far easier to apply in blend:

<Image Source="flatiron.jpg" RenderTransformOrigin=".5,.5">  
    <i:Interaction.Behaviors>
        <lcl:ZoomingBehavior MaximumScale="100"/>
    </i:Interaction.Behaviors>
</Image>  

There you go, an easy way of adding mouse wheel zooming to an element in WPF. I am not entirely happy with using a behavior to modify the render transform of an element, so maybe in a future post I’ll create a custom control that can be used to wrap content in a zoom-able container.

Here is the source code including both the attached behavior and the blend behavior: ZoomBehavior.zip

-AH

The guys over at Parallel Programming with .NET Blog have a great write-up about how to encapsulate this pattern into a Task. It seems they've also written extension methods for common BCL objects that implement this pattern in the Parallel Programming Samples.

Instead of constructing a Task directly, using this pattern, we retrieve a Task from a TaskCompletionSource. This object contains methods for controlling a Task object that it manages. After creating a TaskCompletionSource, we execute the asynchronous operation, and report to the TaskCompletionSource when the operation is finished, cancelled, or has an error. By putting all this logic into a static function, we make it really easy to create a Task to asynchronously retrieve a Stream from a Uri:

private static Task<Stream> StartReadTask(Uri address)  
{
    WebClient webClient = new WebClient();
    var tcs = new TaskCompletionSource<Stream>(address, 
        TaskCreationOptions.DetachedFromParent);

    OpenReadCompletedEventHandler handler = null;
    handler = (sender, e) =>
    {
        if (e.UserState == tcs)
        {
            if (e.Cancelled)
                tcs.TrySetCanceled();
            else if (e.Error != null)
                tcs.TrySetException(e.Error);
            else
                tcs.TrySetResult(e.Result);
        }

        webClient.OpenReadCompleted -= handler;
    };

    webClient.OpenReadCompleted += handler;
    try 
    {
        webClient.OpenReadAsync(address, tcs); 
    }
    catch
    {
        webClient.OpenReadCompleted -= handler;
        tcs.TrySetCanceled();
        throw;
    }

    return tcs.Task;
}

As you can see, this function is responsible for actually calling the methods on the WebClient class that we are using to retrieve a Stream to the given Uri. It returns a Task, but it is slightly different from other Tasks that we are used to using. For instance, if you try to call Start on it, an exception will be thrown. This is because the Task isn't encapsulating work, it is more like a reporting mechanism for work being done. But, we can still use it to determine when the work has completed, like so:

Uri url = new Uri(uri);  
Task<Stream> t = StartReadTask(url);  
t.ContinueWith(ReadRssStream, TaskContinuationOptions.DetachedFromParent,  
    TaskScheduler.FromCurrentSynchronizationContext());

Since we are using the TaskScheduler from our current synchronization context (our UI thread), the ReadRssStream method will be run on our UI thread. In this method, we take the Stream that was retrieved in our Task, and attempts to parse it into RSS or Atom, and adds the items to the ObservableCollection of SyndicationItems:

private void ReadRssStream(Task<Stream> task)  
{
    if (task.Status == TaskStatus.RanToCompletion)
    {
        XmlReader rdr = XmlReader.Create(task.Result);
        IEnumerable<SyndicationItem> items;
        if (!TryReadRss(rdr, out items))
            TryReadAtom(rdr, out items);

        if (items == null)
        {
            Error = "No Rss feed found at the given url.";
        }
        else
        {
            _rssItems.Clear();
            foreach (var item in items)
                _rssItems.Add(item);
        }
    }
    else if (task.Exception != null)
    {
        Error = "Address Not Found.";
    }
}

In our Window, we just bind a ListBox to the list of feeds. The DataTemplate could probably be improved to show a prettier representation of the content, but this worked for this sample app:

<ListBox x:Name="_feeds"  
         DockPanel.Dock="Left" 
         Width="350"
         ItemsSource="{Binding RssItems}"
         ScrollViewer.HorizontalScrollBarVisibility="Disabled"
         HorizontalContentAlignment="Stretch"
         SelectionChanged="OnSelectedFeedChanged">
    <ListBox.ItemTemplate>
        <DataTemplate>
            <StackPanel Orientation="Vertical">
                <TextBlock FontSize="14"
                           FontWeight="Bold"
                           TextTrimming="CharacterEllipsis"
                           Text="{Binding Title.Text}"
                           Margin="0,0,0,4"/>
                <TextBlock TextWrapping="Wrap"
                           Text="{Binding Summary.Text}" />
            </StackPanel>
        </DataTemplate>
    </ListBox.ItemTemplate>
</ListBox>  

I'm really starting to like the new Task API. It definitely seems to make writing parallel / asynchronous code easier. Maybe after playing with it a bit more I'll have some complaints, but it certainly has been pretty nice so far!

Since this post is using features new to .NET 4.0, it was built using VS 2010 Beta 1.

Here is the source: RssViaTasks.zip

-AH