Most days at work, I spend my time coding with Visual Studio 2008. I do ASP.Net development, and Visual Studio is pretty swell for working with ASP.Net. However, sometimes it’s a little bit…heavy for what I need. Sometimes, I’m just writing some JavaScript and I feel like using a nice text editor (like my current favorite TextMate clone). Unfortunately, when I’m not using Visual Studio it’s not as easy to use one of my favorite features of Visual Studio: the built in web server.

While it’s fairly well known that the Visual Studio web server can be run from the command line, it’s a little awkward to type out the full path to the directory I’m working in when I want to start the server up. Luckily, this can be easily remedied with a quick registry edit that creates a folder contextual menu that will open the web server for a directory.

First, if you’re going to be making changes to your registry Back It Up First

Creating a new contextual menu

Once you’ve backed up your registry, you will need open the registry editor. Click on the start menu and choose “Run…”. Type “regedit” in the prompt and hit enter. Next, you will need to navigate to the registry entry that needs to be modified. The key you will be modifying is located at:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell

When you find the key, right click on the shell entry under Folder and choose New->Key from the menu. Whatever you name your new key will be the name of the option that shows up in the contextual menu. When you’ve named your key, right click on it and choose New->Key and this time name the new key “Command”.

Click on the Command and you should see a key named (Default) to the right of it. This is the key that tells Windows which application to pass your folder to when you choose your new contextual menu option. You will need to edit the new (Default) key, but the value you enter will depend on which version of Windows you are using and which version of Visual Studio you are using. I entered a key for Windows XP x64 with Visual Studio 2008, but you may need to modify the key for your specific environment.

"C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\9.0\
WebDev.WebServer.EXE" /port:80 /path:"%1"

The real key, of course, needs to be one line

The first part of the key:
“C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\9.0\WebDev.WebServer.EXE”
specifies where the web server application is located. This is the part that may be different on your computer.

The second part of the key:
/port:80 /path:”%1″
is the parameter string for the application.
%1 represents the path to the folder that is tied to the contextual menu.

If you’ve done everything correctly, you should immediately see a contextual menu that looks like one below when you right click on a folder.

Clicking on this new menu option should start up the Visual Studio web server with the folder you selected as the root folder for the site. One caveat is that the web server will throw an error if an instance of the web server is already running for the same port. I still haven’t figured out a way around that.

One of the many little things that annoys me about Windows is the inconsistency of where items are placed in contextual menus. Case in point: the menu that pops up when you right click on a taskbar item or window. I haven’t done a scientific study, but I’m going to guess that 80% of the time or more the last item in this particular contextual menu is the option to close the window that is being right clicked on. This is what the majority of the contextual menus look like:

Having it as the last item makes sense. It’s probably the most commonly used menu item and it’s an easy target when it’s the last item in the list. The problem is: because that item is listed as the last item over 80% of the time, I start to expect that it’s always going to be the last item in the list. Unfortunately, that’s not always the case.

For whatever reason, some applications list other options below the Close option. Here’s an example of the right click menu for a cmd.exe window:

When I want to close that window, I right click on the cmd.exe item in the taskbar and choose the last item that pops up. But it’s not going to close the window. Instead it’s going to bring up the properties dialog for the cmd.exe window. Now, not only do I need to close 2 windows instead of 1, I also need to always remember that cmd.exe breaks the convention and lists Close as the 4th item up from the bottom of the menu.

Here’s another example:

That’s the right click menu for SQL Server Enterprise Manager. It’s outdated now, but it used to be the main tool for dealing with SQL Server databases. Like cmd.exe, this application also lists an item below Close in the contextual menu. What’s even more annoying in this case is that the item listed below Close is Help Topics. It’s another option that I will accidentally click on instead of the option I wanted, but, this time, choosing the wrong item will start up another application. And, no matter what computer I’m working on, the help application always seems to take a painfully long amount of time to open up.

Now, I would be able to excuse all of this if it was just 3rd party developers who weren’t following the conventions set up by other Windows applications. The problem is: cmd.exe is a integral part of Windows and Enterprise Manager was Microsoft’s official application for SQL Server Databases. So it’s Microsoft that’s disregarding an informal convention and randomly placing items below the Close option. I can only hope that Microsoft plans on dealing with this problem with Windows 7.