I wish I’d had Korby Parnell’s blog around about 10 months ago; it would have saved a lot of headaches.

A long time ago (well, a long time ago by .NET standards), I was trying to get the directory structure of a project set up. The project already existed in Source Safe, and I was trying to figure out how to get integrated source control to work properly with the two web-based components of the solution.

The project consisted of a Web Services (ASMX) tier, a web client (ASPX), and a bunch of component libraries. It was laid out pretty much like this in VSS:

$ProjectRoot
   /SOURCE
       /ProjectNamespace.WebApp
       /ProjectNamespace.WebServices
       /ProjectNamespace.ComponentPackage1
       /ProjectNamespace.ComponentPackage2

Etc. There was a lot more in VSS, but you get the picture.

This structure was intended to be mirrored on the physical hard drive like so:

d:\project
d:\project\source\
d:\project\source\ProjectNamespace.WebApp  -> Hosted in IIS VRoot named “WebApp”
d:\project\source\ProjectNamespace.WebServices -> Hosted in IIS VRoot named “WebServices”
d:\project\source\ProjectNamespace.ComponentPackage1
d:\project\source\ProjectNamespace.ComponentPackage2

I say “intended to be mirrored” because I had some problems actually achieving this with VSS integration. Visual Studio would pull down the appropriate files during the “Open From Source Control” operation, but it insisted in creating the VRoots for the web projects at c:\inetpub\wwwroot. This was problematic because the source code for everything else lived under d:\project\source and I didn’t want code stored in two places on the physical drive.

I attempted to outsmart Visual Studio, by creating the VRoots in IIS ahead of time – the theory being that VSS Integration would create the projects using the existing VRoots, which were pointed at the correct physical location. However, that didn’t work because Visual Studio complained that there was already a VRoot with that name! I learned several months later via an MSDN TV episode that Visual Studio 1.0 will happily use existing VRoots so long as the name of that VRoot matched the name of the physical directory to which that VRoot is pointed (this is a bug in the project creation routines in VS 1.0). Things were breaking because there was a VRoot named “WebApp” pointed at a directory named “ProjectNamespace.WebApp”, which Visual Studio wasn’t very happy about. Had I changed the name of the physical directory to match the VRoot it probably would have been just fine – but, like I said, I didn’t know about that particular bug at the time all this was going on.

Someone suggested a different workaround that involved changing the physical location of the default website from the IIS default (c:\inetpub\wwwroot) to our project’s home directory (d:\project\source). While this eliminated the need to pre-create VRoots and ensured that the VRoots were created by Visual Studio in the correct physical location, it had the side effect of breaking Visual Studio’s ability to actually put files into those VRoots! By default, Visual Studio uses UNC file shares to do file IO for web projects. It assumes that any files accessible via a VRoot will be accessible through some subdirectory off the \\machineName\wwwroot$ share. The problem is that the wwwroot$ is an administrative share created and maintained by Windows, and as such you can’t delete it, rename it, or change it’s location very easily (at least not on Win2K, from what I found). Again, I probably would have been OK if I’d hacked the registry on the dev box to point wwwroot$ at d:\project\source, but I didn’t think of that at the time. Thinking back on it, I wish I would have investigated this a little more, but still – I shouldn’t have to hack locations of administrative shares just to get Visual Studio to put my files where I want them.

I managed to get things sort of working by pulling down all the project files via SourceSafe Explorer, setting up the appropriate VRoots in IIS, and then opening the solution for the first time in Visual Studio. In order to do this, the web projects had to be added to SourceSafe by hand – and I ended up with some of Visual Studio’s top-secret files in Source Safe when they shouldn’t have been. This caused numerous problems with SourceSafe bindings and things just didn’t seem to ever work “quite right.” At that point, I ripped out Visual Source Safe integration and just decided to use SourceSafe Explorer exclusively. As a consequence, I wasn’t able to take advantage of the productivity gains that integrated source control offers.

Now that it’s nine months later and I’ve learned a thing or two (check out this article on MSDN), I wish I had the opportunity to set that project up from scratch again. Looking back with the aid of the knowledge I’ve gained since then, I’ve realized that I took a few wrong turns:

• Not naming our physical directories the same as the IIS VRoots they corresponded to
• Adding ASP.NET projects to Source Control by hand
• Not starting with the “blank solution in SourceSafe” approach
• Trying to use both SourceSafe Explorer and Visual Studio to set up the solution.

I think Visual Studio 1.1 solves the naming bug, but I’m not sure. Regardless, I don’t the VSS Integration story is fully baked yet (especially when it comes to web projects). It’s too bad that I had to fight so hard against the tools to get the desired results – which I could only achieve by abandoning the tools entirely. Word on the street is that Visual Source Safe will undergo some hefty changes in the Whidbey timeframe; all I can say is that I'm looking forward to them.