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.

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.

Now that Microsoft has hired Rob Conery from the SubSonic project I’m hoping and praying that Microsoft will put as least as much energy behind SubSonic as they put behind their own .NET projects.

Today, I needed to add another filter to an existing query that was created with a popular ASP.NET ORM that will remain nameless (it’s not SubSonic). I started by trying to decipher the 30 or so lines of code that created the query, but after around an hour of screwing around with it, I had made no progress. Finally, I gave up and asked a fellow employee who is more experienced with this particular ORM if he could figure out exactly what I needed to do to modify the query. Another 15 minutes of staring at the screen and we had finally determined what the intent behind the query was, and where I needed to add another line to filter on the field I wanted to filter on. Now, I concede that maybe I’m an idiot, and that’s why I couldn’t figure how to change the query. But my fellow employee is not an idiot and it still took him much longer than I think it should have to make a change to a fairly simple query.

This isn’t the first time I’ve run into problems with this ORM (it’s not even the first time this week—and it’s only Tuesday). Had we (the fellow ORM enthusiasts and I) have known how troublesome it would be, maybe we wouldn’t have chosen it. But when we were first looking for a decent ASP.NET ORM (around 2 years ago) there really weren’t a lot of viable options out there that offered stability and flexibility, and didn’t require hundreds of lines of XML configuration. So we chose it. And we convinced the skeptics that it was great by showing off how much time it shaved off simple CRUD tasks. And, in the end, everyone learned to use it. Even if it meant coding around some of it’s shortcomings.

But now there are options. Really, really good options, like SubSonic. I’ve been following the SubSonic project for while, and I’d love to use it for a new project. The problem is that it’s another new ORM to learn. And while I’m willing to learn it, I can’t guarantee that everyone working with me on a project is going to be willing to or have the time to learn it. It was a big enough hurdle to convince people that our current ORM (as complicated as it is) was the right option. Now that I’ve changed my mind about it, how can I convince people that SubSonic is going to be any better?

I’m hoping that Microsoft will do the convincing for me. Now that Rob Conery is at Microsoft, I’ve sort of taken for granted that SubSonic will be the default model layer for Microsoft’s new ASP.NET MVC framework. But Microsoft already has other technologies (like LINQ) that could be used in the place of SubSonic for database connections. Personally, I don’t think Microsoft offers anything that has as much potential as SubSonic. My hope is that, even though it wasn’t invented at Microsoft, and it’s a open source project, Microsoft will still put some muscle behind SubSonic. Not just development muscle, but maybe a little marketing muscle too. At least the same kind of marketing they use for the rest of ASP.NET. If only so that someday I’ll never use our current ORM ever again.