Here's my Source Control Tip of the Week:
<<Create a blank solution before creating a project.>>
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
Answer: First, doing so encourages good
housekeeping. Second, it can help you and
your teammates avoid some unnecessarily complex branch/merge and bind/unbind
a two-project solution, if you first select File->New->Project, and then
add a second project the outcome is:
Proj1 (folder) $/Proj1.root
|-.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
.ROOT Folder and "Unified Root".
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