(Or rather “How a fixed bug and a rubbish COMException error dialog ended up making me take four months to learn that Web Application Projects running on IIS rather than Cassini can only be edited in VS when running with Administrative privileges” but that seems slightly long for a blog title post)

I’ve been happily running VS2008 as a standard user since it came out. And with TestDriven.NET and VisualSVN, I’m motoring along quite well. Yesterday, I decided to upgrade VisualSVN to the latest version v1.5.1. And then bang!! I loaded up my current work and got this dialog.

ExceptionDialog_3

And my Web Application Projects have failed to load in VS2008. After mild panic has finished setting in, I try regressing to my previous version v1.3.2 and the project loads fine. Which is mildly inconvenient as v1.3.2 doesn’t work with TortoiseSVN 1.5 which is something I also updated on my machine.

Looking on the intarwub, it’s mildly amusing to see that Google’s best match to this situation as I search for it is a forum thread that I started on VisualSVN’s forums when I got the same error trying out v1.4. However, one response in there since I last read it suggests removing the <FlavorProperties> element from the wap’s .csproj file. Which I do and it works. But having loaded the project back in again and reset it back up to run on IIS, the dialog appears again.

A bit more googling for Web Application Projects and COMExceptions yields this page from Martin Kulov bemoaning the same useless dialog but with the following golden nugget of information.

In order to load the Web Application Project ... if you are running Vista, you should run in elevated privileges as well.

Which is a bit of a shock as I’ve been happily running Vista and developing this project as a standard user for four months. Furthermore, it turns out that that useless dialog is a VS2008 bug that will be fixed in Service Pack 1.

So apologies to VisualSVN for doubting you. I’m never a fan of running Visual Studio as an admin, but I guess I have no choice. But whatever bug was present in v1.3.2 so I could develop WAPs on IIS as a standard user, maybe you could put it back? :)