Tag Archives: Visual Studio


I recently came across this awesome code kata performance by Corey Haines here.

Besides enjoying and learning from his actual performance, I was really impressed by his use of a Ruby tool called autotest. (I’m not sure, but it looks like it has become autospec.)

Not being a Ruby developer, I wanted the same thing for .NET. I did some searching, but my Google-fu failed me so I spent an hour hacking together my own.

The result is called AutoRunner (I know–way creative) and its source is available on GitHub.

If you want it, you have to download the source and compile it yourself for now. (UPDATE: You can now download it here!) Run it from your favorite console (PowerShell, right?) without any arguments to see what options it accepts.

AutoRunner is a little more general purpose than autotest/autospec is. Basically, it can run any executable when any file changes.

What I wanted it for was to run nunit-console.exe whenever my current tests assembly was rebuilt. To do that, I just invoke it with the right arguments.

If you have Growl for Windows running, it will send it a notification which is pure eye candy and not necessary to actually get it to run your tests.

It’s not a Visual Studio add-in. It’s just a plain old console application. Using Visual Studio’s External Tools feature, however, it’s almost as good as an add-in. I set up an external tool with the appropriate arguments and it’s good to go for all of my projects.

To set this up for yourself, you’d create a new external tool with its command set to the path where you built AutoRunner.exe and its arguments set to something like the following (I’ve separated the options on their own lines, but you wouldn’t do that in Visual Studio):

--target $(BinDir)\$(TargetName)$(TargetExt)
--exe C:\path\to\nunit-console.exe
--pass "$(TargetName) FTW!"
--fail "Oh noes! $(TargetName) is FAIL!"

You can use whatever test runner you like, of course. Please note that you must have a file from your tests project open or selected in Solution Explorer when you activate the tool or your AutoRunner instance will be watching the wrong DLL!

It doesn’t support plug-ins the way autotest does and most of its functionality is hard-coded for now. If anybody finds it useful, let me know and maybe we can work on improving it together.

Verifying JavaScript with JSLint and Visual Studio

Douglas Crockford’s JavaScript: The Good Parts is a short, but informative read that all JavaScript developers should probably pick up. In it, he describes what parts of the JavaScript language we should be using (the good parts) and what parts we shouldn’t (the bad and the awful parts).

To help keep ourselves in check, he’s made his JSLint tool available years ago, but I always found myself too lazy to copy/paste my script into the tool to verify it. I finally decided to make this an almost instantaneous process.

The source code for JSLint is written in, what else, JavaScript. Since I do the majority of my work on Windows machines, I’m fortunate enough to have a built-in scripting engine that can run JavaScript without having to install any extra tools. And, no, I don’t mean my web browser—I mean cscript.exe.

Mr. Crockford does have a simple, cscript-compatible version of his script on his web site. It’s too simple, though. Most of the options it can check are disabled so aren’t checked and it stops after finding its first error.

For that reason, I’ve put together my own “host” for JSLint. It supports the enabling and disabling of all the options listed on the JSLint documentation page with command-line parameters and includes reasonable defaults so that you shouldn’t need to set or unset too many.

I’ve also added an option that adds the global variables defined in the Microsoft AJAX Library so that you don’t have to declare them in each of your scripts or on the command line. I’ve turned that option on by default, but it shouldn’t hurt you if you’re not using ASP.NET AJAX.

It also outputs any errors it finds in a format compatible with Visual Studio. If you set it up as an external tool, you can run it against your current file and hit F8 (the key bound to Edit.GoToNextLocation, by default) to jump to each line an error occurred on. This makes it trivially easy to detect and fix errors. No more excuses for using the bad parts of JavaScript!

To use it, all you have to do is download the latest version of fulljslint.js from the JSLint web site. Put it in some folder in your PATH. For example, I use a folder called C:\Tools to hold the various little tools I find myself needing frequently. Next, download jslint.wsf from this web site and put it in the same folder you put fulljslint.js in. Finally, download jslint.cmd and, once again, save it in the same folder as the other two files. You should now be able to issue a simple command like the following to verify any JavaScript file:

jslint script.js

Of course, to get the most out of using this, you’re going to want to set it up as an external tool in Visual Studio. Open up Visual Studio, go to Tools -> External Tools… and click Add. Enter “&JSLint” as the Title and “C:\Tools\jslint.cmd” (modified to use the folder you actually saved the files in, of course) as the Command. Enter “$(ItemPath)” as the Arguments. Check Use Output Window and click OK.

To test it out, open up any .js file and hit Alt+T and then J (or use the mouse). You should see your Output window appear with the results of the run. If there were any errors just hit F8 to cycle through them.

If you’re confused about why it’s saying such simple things like == and ++ are errors, read Douglas’ book or at least read the documentation for JSLint and the other essays on his web site.

A quick tip for ASP.NET AJAX users: If you register your own namespaces using Type.registerNamespace, you’ll get many errors telling you that your namespace is undefined. Put a comment like this at the top of your file and you’ll be good to go:

/*global YourNamespace*/

Feel free to contact me with any questions or issues you might have. I really want to see us all improve as JavaScript developers so the more people who are using tools like this, the better our code will be.