Visual Studio Web Projects considered harmful

When you want to work on a web application in Visual Studio the default behaviour is to use a project that uses Frontpage server extensions. (Web applications include ASP.NET projects or Web Services.) There are big problems with this:

– Every development environment must have IIS setup, even if its used for working on part of the app separate from the web project.

– Every development environment must have IIS setup, even if an alternative ASP.NET runtime is being used (e.g. Cassini)

– Every environment must have a virtual directory set up with a common name (this is similar to the Common Absolute Paths Anti Pattern)

– Source Control Integration is often problematic

The solution to this problem is to just use plain DLL projects. You’ll need to explicitally add references to the System.Web assembly, but that’s basically it. You’ll probably want to change the Debug and Release ‘output’ paths to just ‘bin’ aswell, since that’s the default for web apps.

One restriction is that out of the box Visual Studio won’t allow you to create a new aspx/asax page and associated code behind using ‘Add new’ on the project for a DLL project. There’s a work-around, but it needs to done for every developer environment. Here’s how:

– Go into C:\Program Files\Microsoft Visual Studio .NET 2003\VC#\CSharpProjectItems\WebProjectItems\UI and open the ui.vsdir file

– Copy the lines that end in WebForm.aspx, WebUserControl.ascx, HTMLPage.htm, Frameset.htm, StyleSheet.css, and the ‘mobile’ types if you want them too.

– Paste the lines into C:\Program Files\Microsoft Visual Studio .NET 2003\VC#\CSharpProjectItems\LocalProjectItems\UI\ui.vsdir

– When you choose ‘Add new item’, the web templates will now appear in the ‘UI’ subfolder (you may need to restart Visual Studio first)

2 notes – if you installed Visual Studio somewhere else you’ll need to adjust the paths, and you should also backup the us.vsdir file you are changing. (Thanks to Owen Rogers for pointing out this workaround)

Some other behaviour you get for free when you do use web projects is:

– Hitting F5 launches a browser window at your default page

– You can debug the server side of your application

If you switch to using DLL projects you can still debug your ASP.NET hosted application by using one of the following alternatives

– The easiest way is to manually ‘attach’ to the ASP.NET worker process (In Visual Studio, go to ‘Tools -> Debug Processes’, and select ‘aspnet_wp.exe’). This process automatically starts the first time you access a ASP.NET resource. Doing this will mean you can debug the server-side of your application as normal.

– Alternatively, you can set the debug properties on the DLL (right click on the project, select ‘Properties’, then select ‘Debugging’ in ‘Configuration Properties’). Set ‘Enable ASP.NET Debugging’ to true, set ‘Debug Mode’ to URL, and set the ‘Start URL’ as required (there seems to be a bug in VS where you need to reopen the properties box to be able to set this last property.)

Benefits to this scheme beyond solving the original problems are:

– Since all source is developed under one tree it is much easier to work on 2 copies of the same project on one machine

– Similarly to the above point, it is much easier to work concurrently on more than one branch of the same project on one machine

– Its faster – visual studio just needs to use file access

– Its simpler – developers are already used to working with dll projects so they don’t need to learn anything new.

– You can compile, and run tests that don’t depend on retrieving web content, without having IIS running.

%d bloggers like this: