Guidance on Creating Projects and Solutions

Here’s my Source Control Tip of the Week: 

<<Create a blank solution before creating a project.>>

In  href="">Web
Projects and Source Control Integration in Visual Studio .NET,  I state
that doing so will, “

…improve the long-term manageability and discoverability of your projects [and] maintain a close symmetry between local project
files and their master copies on the source control server

An inquisitive reader asks, “How does creating a blank
solution as opposed to creating a solution along with a project template –
“improve the long-term managability and discovery of your projects … symmetry
between local project files and their master copies on the source control
server. In general what is the best way to set up VS.Net projects that integrate
with VSS.”

Answer:  First, doing so encourages good
.  Second, it can help you and
your teammates avoid some unnecessarily complex branch/merge and bind/unbind


Workspace Mapping
When creating
a two-project solution, if you first select File->New->Project, and then
add a second project the outcome is:

Explorer           On
Disk                     VSS

Proj1 (folder)             $/Proj1.root
|-Proj2                          |-proj1.sln                        
|-.vbproj, etc                     |-.vbproj

Whacky huh? Your “logical view” in Visual Studio differs from the
“physical view” on disk and in the SCC database. The first problem with this setup boils down
to what I call ‘human namespace tracking’. Proj1 is the name
of the solution (?) AND one of its projects?  Second problem: in your Visual Studio
Projects directory, there’s no way to ascertain the relationship between Proj2
and Proj1 because both folders are created at the root directory level. 

Note: for an explanation of the “.root” folder above, see my recent
post:   href="">The
.ROOT Folder and “Unified Root”.

Complex Scenarios
Scenario A: If you create a solution via the New Project dialog box and then add
two more projects, you have created 4 containers; three projects and one
solution (in Solution Explorer). When you add the solution to source control
though, only three folders are created in the source control database. Why? When
you add the solution and initial project to source control, the SCC
provider does not differentiate between the project and solution–and this
is the important part–because the initial project file (*.*proj) and the
solution file (*.sln) occupy the same folder on disk. Therefore, the source
control provider creates a single binding for both containers. Internally, we
discuss solutions and projects in terms of bindings, or connections between the
working copy of a project or solution and its master copy under source control.
You may recognize these words, which appear in Visual Studio’s Change
Source Control dialog.

Scenario A1 (Siamese project Twins).  If you create
a solution and the initial project simultaneously, they are conjoined by
location on disk and they are conjoined by location under source control. 
If you should ever need to remove the first project (Proj1) from source
control and if you have since added additional projects
(Proj2 and 3), you cannot easily unbind Proj1 without also unbinding the
solution. To do so, you soon discover, you must also unbind
Proj2 and Proj3 from source control because Proj1 and the solution share
a binding and Proj2 and 3 are linked to the solution under source

Scenario A2 (Can’t Branch easily): You need to branch only Proj1. Again,
Proj1 is inextricably linked to Sln’Proj1′. Thus, if you branch Proj1, you must
also branch Proj2 and Proj3.

Scenario A3 (Can’t Add to SC): You add Proj4 to Sln
‘Proj1’, add a file from Proj1 to Proj4, write some code, and then attempt to
check in your changes. Behind the scenes, your source control provider attempts
to add Proj4 to source control. A message might appear that says something like,
The project cannot be added to source control because it overlaps a project
that is already bound to source control at a lower root.

By employing the blank solution project creation method, you avoid these and
other complex scenarios because Proj1 and its solution each have their own
bindings and can be managed as atomic entities under source

This posting is
provided “AS IS” with no warranties, and confers no

Comments (6)

  1. Charlie Hensler says:

    I’ve been working out some development environment issues between VS and VSS. I’m struck by how the relationship to VSS (from VS) is straightforward until you create a web project.

    A difference with web projects is that – unlike other project types – Visual Studio asks you to specify a vdir, not the physical location of the project files, and then by default creates a directory for the project files…somewhere.

    The team dev environment documentation devotes a fair amount of text to steps required to work around this default behavior.

    Would it make more sense – when creating a new web project – for Visual Studio to ask you for the location of the physical directory for the project files (defaulting to a sub directory under your solution directory, for example)? Visual Studio could then create the vdir pointing to that physical directory?

  2. Good observation. This is the default behavior in the next version of Visual Studio. :-)

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