In a recent post, Chris Flaat offers some good advice for developers who include "linked files" in their source-controlled projects. Linked files, which are also called "reference files" in some language projects, are files that do not occupy the same drive or directory on disk as the project file itself. Chris explains that adding linked files to your source-controlled projects can complicate the management of projects in Visual Studio .NET. Somewhere in this explanation, he refers to the concept of a "unified root". 

A unified root is the folder in an hierarchical directory beneath which all the files referenced by a [source-controlled] solution or project can be found. Chris Flaat defines it as "the closest common parent to all the files in the project" (which is a great definition except that I would replace the word project with 'solution'). C:\ is the unified root of a solution whose solution file (*.sln) lives at c:\solution1.sln and whose one project lives in c:\projects\ProjA.csproj. So what is the unified root of a solution whose .sln file lives in C:\Solution1 and whose only project lives in D:\ProjA?  No existe. Since C:\ and D:\ are inherently parentless directories, Solution1 is without a unified root.

In Visual Studio .NET 2002 (v1), such "Unified Rootless" solutions occasioned a number of hard-to-explain source control foibles, especially in the context of multi-project solutions. The end user experience was good, but not excellent.  Two of the most noticeable foibles were seemingly redundant SCC prompts and a 'Yes All' button that did not always work as expected when performing batch SCC operations.

Recently, several VS.NET 2003 (v2) customers have inquired about a "mysterious" new folder (SolutionName.root) that keeps showing up in their source control databases when adding solutions to SCC via Visual Studio .NET 2003 (aka "Everett"). It's not a Microsoft conspiracy, I promise :-). It's a feature.

To elevate the user experience from good to excellent, the SCC feature team implemented a simple and elegant fix in VS .NET 2003 that creates an empty .ROOT folder in the source control database and then adds child folders for the solution and projects thereunder. Essentially, the empty .ROOT folder maps to an as yet undefined and uncalculated  [Blank**]-Unifed Root, with the following benefits (partial list):

  • Fewer SCC Prompts--now, you can create a solution, populate it with three new projects, add it to source control, and experience the magic of... nothing.
  • Parallel File Organization--now, if your solution and projects all reside on a single drive, their source control "view" (hierarchical organization) is practically the same as their logical "view" in Solution Explorer*. This organizational parallelism has many benefits, especially in the area of advanced source control operations such as binding-unbinding and sharing-branching-merging.
  • Supports the Concept of a [Blank**]-Unified Root--Now, if you add a project to a source-controlled solution whose files reside on a different drive or computer, perhaps a Web project by UNC path, the new project is added to the repository under the .ROOT project as a peer to the folder containing the solution with which it is associated. Previously, this project would have been orphaned in the source control repository with nothing to inform you of the initimate relationship between it and the solution to which it belongs. In my opinion, this is one of the best reasons to leave this feature on...

I've heard a few academic complaints that the creation of the SolutionName.root folder conflicts with the guidance offered in our Team Development Guide and the whitepaper that Martyn Lovell and I wrote a while back. Technically, this is true. In reality however, this feature change is perfectly congruent with that advice and indeed, maintains an SCC folder structure that mirrors what you see in Solution Explorer. Thus, I would more readily advise you to revise your build process slightly than turn off the creation of the .ROOT folder.  In fact, I plan to suggest that the BuildIt.net tool (which is based on the Team Development Guide) be updated to accomodate the .ROOT feature. Nevertheless, I'm not one to hold back information unless I absolutely must. So here it is. You can turn off this feature in VS.NET 2003 using the following procedure:

1.      Click Start, click Run, type Regedit, and then click OK.

2.      Open HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\SourceControl

3.      Select key DoNotCreateSolutionRootFolderInSourceControl, click Edit, and then click Modify.

4.      In the Value data box, change 0 to 1, and then click OK.

Caution   Mucking with your registry can do irrevocable harm to your computer. Be careful.

Side Note  Recently, I've been thinking about how to describe the relationship between a solution's logical organization in Solution Explorer, the topology of the physical folders in which its constituent files reside on disk, and the organization of the solution in the source control repository. Any thoughts on what I should call these conceptual "views" of a development project or solution.  Is "workspace" too generic or overloaded?

As always, comments of all shapes, sizes, and languages are welcome.

*If, as I strongly recommend, you create a separate directory for the solution when creating your first project or if you create a blank solution and then add projects to it, your source control "view" and logical "view" in Solution Explorer will be exactly the same as your solution's file structure on disk.

**[Blank] is a type of overarching Unified Root that exists above drives (eg, C: and D:) and mapped drives and is thus "virtual" by nature.  We've considered a few alternatives that have since been ruled out, for one reason or another, including Virtual, Meta-, and Über-.  My favorite is Über ;-). Super is still under consideration, I think...  Any other ideas?

This posting is provided "AS IS" with no warranties, and confers no rights. Microsoft kann für die Richtigkeit und Vollständigkeit der Inhalte in dieser Newsgroup keine Haftung übernehmen. Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.