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.

On Saturday I woke up early and headed to an estate sale down the block from me. I was hoping to find some cheap records or a CD shelf or something. Instead, I found a Fender Vibrosonic amplifier and a Miller Custom pedal steel guitar. I placed a bid on both, thinking that my bid was way too low. But the other guy who had placed a bid didn’t show up, so I won both!

Here’s a little Ruby script that can be run on a new Visual Studio solution file. It will turn off dynamic ports and set the root of your site immediately after the hostname.

File.open(ARGV[1], 'w') do |modified|
  File.open(ARGV[0]).each do |line|
    modified.puts line =~ /VWDPort/ ?
    %{\t\tVWDPort = "80"
\t\tVWDDynamicPort = "false"
\t\tVWDVirtualPath = "/"} : line
  end
end

Run it from the command line with the input solution file first and the name for the new solution file second.

ruby fix_solution.rb MyProject.sln FixedProject.sln

When I develop my sites locally using Visual Studio, I like to have the conditions on my local machine match the conditions on the actual web server as closely as possible. Part of doing that is making sure that my urls are formatted the same locally as they will be on the live site. Unfortunately, by default, Visual Studio’s built in web server makes the urls for a local project look a little bit different than they will when the site is actually deployed. This can be remedied quickly with a few changes to your project’s properties.

The Issue

When you first start a new project up in the debugger, Visual Studio will start the built in web server and open your default web browser with a url that looks something like this:

http://localhost:8080/Demo/Default.aspx

There are few problems with this url. First, the web server is not running on port 80, so the url contains the port number for the web server. This is an aesthetic problem, but it can also create issues if you plan on having your site behave different based on values that are found in the hostname. For example, if you have a site that has separate subdomains like “people.example.com” and “places.example.com”, and each of those subdomains shares the same codebase, it’s difficult to test that behavior locally if you don’t have your site running on port 80.

A second problem is that instead of having the root url immediately after the hostname, Visual Studio treats “/Demo” as the root of your site. This causes all kinds of problems if you want to use relative urls. It can also cause problems if you want use a url rewriter that relies on regular expressions to determine where a url goes.

Here’s how you can fix it.

Setting the Web Server Properties

To fix the port number and the site root problems, first open the Solution Explorer tab and select your project in the in the list of items.

Next, open the Properties tab and change the “Use dynamic ports” option from True to False. This should allow you to change the Port number to port 80. One issue that I’ve noticed with various versions of Visual Studio, both full and express, is that sometimes you need to close the Properties tab and reopen it before Visual Studio will allow you to change the port number. Finally, change “Virtual path” to “/” so that the root of your site will be immediately after the host name.

Now, when you start up the built in web server, you should be able to access your local site at “localhost”. No port number or project name after the url hostname necessary.

Creating some urls

At this point, the only url where you will be able to access your local site at is “localhost”. This is fine for simple sites, but I always lke to have a url like “matt.dev” where I can access any sites that I’m running on my localhost. That way, if I need to use subdomains, I can access my localhost using a url like “people.matt.dev” or “places.matt.dev”.

To set up these urls you will need to make some entries in your hosts file. Your hosts file is located at “C:\WINDOWS\system32\Drivers\etc\hosts”. I’ll assume that if you’re running Visual Studio under something other than Windows you already know how to get to your hosts file. Open the file with a text editor like notepad. You will see that an entry like this is already there for localhost:

127.0.0.1 localhost

Underneath this entry you can add your own urls that will point to your local web server. Like this:

127.0.0.1 people.matt.dev
127.0.0.1 places.matt.dev

Once you’ve saved your changes to the hosts file, your urls should point to your local webserver.

Finally, if you’d like Visual Studio to use your new urls when opening a website in the debugger, open right click on your project in the Solution Explorer and choose “Property Pages” (what’s the difference between “Properties” and “Property Pages”? That’s just one of life’s little mysteries). Choose “Start Options” and then “Start URL:”. Now you can enter the url you would like the site to start at when you open it in the debugger.

And just for fun, here’s a Ruby script that will do most of this for you.

The warmth means that it’s time to get back out and explore some places. So far, it’s been a few hospitals this month.

Hospitals