The .ROOT Folder and “Unified Root”

In a recent post, href="">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.  href="">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
defines it as "the closest common parent to all the files in the
(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...
  • 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
  • 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 href="">Team
Development Guide and the href="">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  href="">
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:

style="MARGIN: 3pt 0in 3pt 0.25in; mso-list: l52 level1 lfo868"> face=Verdana size=2>1. style="FONT: 7pt 'Times New Roman'">      face=Verdana size=2>Click Start, click
Run, type class=Bold>Regedit, and then click class=Bold>OK.

style="MARGIN: 3pt 0in 3pt 0.25in; mso-list: l52 level1 lfo868"> face=Verdana size=2>2. style="FONT: 7pt 'Times New Roman'">      face=Verdana size=2>Open

style="MARGIN: 3pt 0in 3pt 0.25in; mso-list: l52 level1 lfo868"> face=Verdana size=2>3. style="FONT: 7pt 'Times New Roman'">      size=2>Select key style="COLOR: navy; FONT-FAMILY: 'Courier New'; mso-bidi-font-family: 'Times New Roman'">DoNotCreateSolutionRootFolderInSourceControl face=Verdana>, click Edit, and then
click Modify.

style="MARGIN: 3pt 0in 3pt 0.25in; mso-list: l52 level1 lfo868"> face=Verdana size=2>4. style="FONT: 7pt 'Times New Roman'">      size=2>In the Value
box, change
style="COLOR: navy; FONT-FAMILY: 'Courier New'; mso-bidi-font-family: 'Times New Roman'">0 face=Verdana> to style="COLOR: navy; FONT-FAMILY: 'Courier New'; mso-bidi-font-family: 'Times New Roman'">1 face=Verdana>, and then click class=Bold>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.

Comments (3)

  1. Google makes me think that your blog must be the best place for discussions of VS/VSS unified roots.

    I’m working in an environment where I have .sln files for different customers. The solution files include projects shared with other customers. As a result, the project files can’t simultaneously be under every solution’s root and VS (2003/2005) complains about the source control bindings.

    The solution of this problem requires the choosing of an appropriate unified root. Unfortunately, the help doesn’t seem to tell you how to set a unified root.

    After much frustration, I discovered a workaround. First, unbind all the projects in the Change Source Control dialog (often requires clicking Unbind for each individual project). Second, select all the projects in the Change Source Control dialog then click Bind.

    VS/VSS then binds to the lowest common folder that’s above all the projects thereby providing a unified root.


  2. Very many thanks for a good work. Nice and useful. Like it!

Skip to main content