Setting up a .NET build server WITHOUT installing Visual Studio

I’ve been tasked with upgrading my client’s build server. It currently builds VS 2080 solutions in .NET 3.5 – and I’ve been pushing to upgrade everyone to Visual Studio (VS) 2010 and eventually .NET 4.0. I want to upgrade the server to build a VS 2010 solution in .NET 3.5. This will allow everyone to upgrade to VS 2010 while leaving the task of upgrading the production web servers to another day.

I try the easy approach. I install .NET 4.0 on the build server and run the MSBuild scripts that already exist.

Nothing good happens. I do a little digging and find out that you need to install the Windows SDK to get MSBuild to work.

So I get the Windows SDK – Microsoft Windows SDK for Windows 7 and .NET Framework 4 – and install it.

Nothing good happens. I dig a little further and find out that by default MSBuild installs pointing at the VS version of the Windows SDK whether it is there or not.

Also, the Windows SDK does not care about the settings of MSBuild, so when you install the SDK it doesn’t fix this or update this. Which I understand from the SDK team’s point of view, but it would have been a nice fix.

Registry View of the MSBuild Settings for .NET 4.0

Registry View of the MSBuild Settings for .NET 4.0

The important thing to note is the keys which have “7.0a” in their values. 7.0a is the version of the Windows SDK that ships with Visual Studio 2010. If you download the SDK from Microsoft you get version 7.1. So I go in and manually change all those 7.0a to 7.1.

It builds! But it fails. For some reason, I can’t get any of the XmlSerializers dll (which are needed by web projects that have web services or WCF) to generate correctly.

The normal dll’s compile into .NET 3.5 versions (which is what I want), but the XmlSerializers dlls all generate in .NET 4.0. What’s going on here?

Another bug. The Windows SDK installer, by default, installs the WRONG keys into the registry. This apparently only affects certain edge cases, like trying to generate XmlSerializer dll’s with MSBuild from .NET 4.0 into .NET 3.5. I’m guessing the Visual Studio installer fixes this when it runs.

The issue is documented here: Windows 7.1 SDK targeting .NET 3.5 generates wrong embedded Resources.

So, another trip to the registry. This time, to the Microsoft-SDKS section. There are two bugs here:
1) All the keys need to have a dash after the “WinSDK” portion
2) Some of the fields have an “-86” in their key, which needs to be “-x86”

A view of the registry for the Windows SDK

The final view of all the keys in the Microsoft-SDKS section of the registry.

One more try. Build successful. 🙂


Enable/Disable jQuery buttons in Knockout with a Custom Binding Handler

Still working on those jQuery buttons, trying to update old ASP.Net Webforms using jQuery, Knockout, and Amplify. New problem today.

I was having problems getting Knockout to enable/disable my jQuery buttons using the Knockout ‘enable’ bindingHandler. It would enable/disable the underlying element that I had run the .button() method on, but it had no idea about the div that jQuery had wrapped my element in, or how to handle it.

So I wrote a custom bindingHandler for Knockout to handle this case. It also can handle non-jQuery elements as well, so you could change the declaration from ‘jEnable’ to ‘enable’, and this would work as a all-comers enable function. However, since this method uses jQuery (and therefore is much expensive than the plain old ‘enable’), I figured the extra binding was the best approach.

if (ko && ko.bindingHandlers) {
    ko.bindingHandlers['jEnable'] = {
        'update': function(element, valueAccessor) {
            var value = ko.utils.unwrapObservable(valueAccessor());
            var $element = $(element);
            $element.prop("disabled", !value);

            if ($element.hasClass("ui-button")) {
                $element.button("option", "disabled", !value);

An example on how to use this:

<input id="btnToEnable" type="button" data-bind="jEnable: isEnabled" />

   var viewModel = { isEnabled: ko.observable(true) };

A gist of this code is located here.

Auto Creation of jQuery Buttons using Knockout Templates

While converting ASP.NET Webforms to be more clienty using HTML 5, Knockout, and jQuery, I came across a problem.

I want to use jQuery buttons on my Knockout-rendered rows, but whenever a new row gets added via a template, the buttons were not being created as jQuery buttons.

The issue was, I was calling a method to create the buttons after the page was fully rendered, but never again. So all the new rows wouldn’t have the .button method run on them, and thus no sparkly jQuery buttons.

What to do? I’ve got button markup that looks like this:

<div class="jButton" data-icon-name="refresh" data-bind="click: refresh">

And some existing code, that given an element with class “jButton” and optionally the data-icon-name set the icon you want, creates buttons out of divs.

I saw one person handle this via a new binding on the button, but I didn’t want to have to change to my existing template to get the behavior I was looking at.

I tried a couple of different options, and while looking through the Knockout examples for other options came across the afterAdd option in the template binding.

So a quick change to my template binding:

<tbody data-bind="template: {name:'rowCostItem', 
                             foreach: CostItems, 
                             afterAdd: function(elem) { var row = $(elem);
                                                        Buttons.createFrom(row); }}">

And now I get nice jQuery buttons for all my new rows.

P.S. The heart of the Buttons.createFrom() method:

    var btn = $(this);
    var iconName ="iconName");
    if (iconName) {
        btn.button({ icons: { primary: 'ui-icon-' + iconName} })
    } else {

Finished the Nike+ Importer for

I finally finished up the Nike+ data importer for

The code for the importer can be checked out at my Github repository:

I got a small test project up for this, which walks through everything but doesn’t Mock up the calls to the Nike+ service (I couldn’t be bothered).

Let me know what you think.

jQuery UI Bug – 1.8.16, buttonset() method

I love to find bugs in good software!

Came across a little jQuery UI bug today. It’s only for one browser, but it always excited to be able to create an easy-to-replicate bug.

The bug is small – it deals with the buttonset() method. The buttons, instead of having the rounded corners on the outside, have the rounded corners on the inside. Not exactly critical, but it definitely made the UI I was working on look strange.

If you have Chrome, and are dealing with jQuery 1.6.3 and jQuery UI 1.8.16, check out the bug here: