This post originated from an RSS feed registered with .NET Buzz by Korby Parnell. Original Post: Guidance on Creating Projects and Solutions Feed Title: Korby Parnell Feed URL: /msdnerror.htm?aspxerrorpath=/korbyp/Rss.aspx Feed Description: Copyright 2003 Korby Parnell Fri, 01 Aug 2003 10:03:48 GMT ChrisAn's BlogX korbyp@microsoft.com korbyp@microsoft.com Alex Lowe Joins Microsoft http://blogs.gotdotnet.com/korbyp/permalink.aspx/536bb108-6a66-4dc6-8847-69f4d799bb55 http://blogs.gotdotnet.com/korbyp/permalink.aspx/536bb108-6a66-4dc6-8847-69f4d799bb55 Fri, 01 Aug 2003 10:03:48 GMT From ASP.NET MVP to Microsoft .NET Evangelist.  Success is the domain of good guys.  Welcome aboard Alex.  I look forward to meeting you in person.  Thanks to ScottW for posting the big announcement. Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho. Latest .NET Buzz Posts Latest .NET Buzz Posts by Korby Parnell Latest Posts From Korby Parnell

Here's my Source Control Tip of the Week: 

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

In 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 housekeeping.  Second, it can help you and your teammates avoid some unnecessarily complex branch/merge and bind/unbind scenarios .

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

Solution Explorer           On Disk                     VSS Database             

Sln 'Proj1'                     Proj1 (folder)             $/Proj1.root
   |-Proj1                          |-proj1.csproj                |-Proj1
   |-Proj2                          |-proj1.sln                         |-Proj1.csproj AND Proj1.sln
                                     Proj2 (folder)                   |-Proj2
                                        |-.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:  The .ROOT Folder and "Unified Root".

--Complex Scenarios--
Problematic 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 control.

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 control.

This posting is provided "AS IS" with no warranties, and confers no rights.