More on: Help Structuring VS2010 Solutions/Projects and TFS2010

Question

This is a follow-on post to our previous post (Help Structuring VS2010 Solutions/Projects and TFS2010).

We have a few questions regarding how to structure our VS2010 solutions and projects for best organization, as well as to save in and use TFS2010.

Currently, our code is structured something like:

/OverallAppName  
OverallAppName.sln  
-/Client  
-    -/WindowsFormsProject1  
WindowsFormsProject1.sln  
-    -/WindowsFormsProject2  
WindowsFormsProject2.sln  
-/Components  
-    -/ClassLibrary1 (common library referenced by other projects)  
ClassLibrary1.sln  
-    -/ClassLibrary2  
ClassLibrary2.sln  
-    -/ClassLibrary3  
ClassLibrary3.sln  
-    -/ClassLibrary4  
ClassLibrary4.sln  
-    -/ClassLibrary5  
ClassLibrary5.sln  
-/Server  
-    -/WindowsServiceProject1  
WindowsServiceProject1.sln  
-    -/WindowsServiceProject2  
    WindowsServiceProject2.sln  
-    -/WebProject1  
    WebProject1.sln  
-    -/WebProject2  
    WebProject2.sln  

Since, right now, we’re in the process of moving from VSS to TFS2010, we’re wanting to structure all our solutions/projects to be most efficient, most logical, easiest to maintain, easiest to reference, and easiest to use with and build in TFS2010, and we’re needing some advice on the “best” way to structure everything with a partitioned solution model.

Any suggestions????? How can we structure all these different types of VS2010 projects into a logical structure that separate groups can work on individual pieces (not the entire solution), we can still have project references, we can stored in TFS2010 and build and branch in there, and follow “recommended best practices”?

Thanks. (Sorry, I'm not sure the formatting came out very good.)

Answer 1

While I admire your commitment to trying to keep everything as one large solution, I think this is going to defeat some of the best features TFS has to offer in the realm of automated builds by sticking to this.

The reason I say that is because you can use builds triggered by check-in to immediately build the code to prove it works (or better yet, use a Gated check-in). The usefulness of these builds are inversely proportional to the time they take to run. So if you have a massive solution that takes 20 minutes to build then it's going to take away from the advantages of those types of builds. If however you had several smaller solutions that took about 5 minutes each then you'll only get the modified solutions building on check-in and know the results sooner.

From what you've listed above I'd be inclined to have a solution for each set of artefacts that can be released separately. In your example that's probably one for each of the clients, one for each of the web applications and one for all of the common libraries.

Folder structure wise it'll not be much different to what you have above (assuming I'm interpreting it correctly)

/OverallApplication
    /Clients
        /Client1
            -Client1.sln
            /Client1Project1
                -Client1Project1.csproj
            /Client1Project2
                -Client1Project1.csproj
            ...
         ...
    /Components
         -Components.sln
         /ClassLibrary1
             -ClassLibrary1.csproj
         /ClassLibrary2
             -ClassLibrary2.csproj
         ...
    /Server
        /WebApp1
            -WebApp1.sln
            /WebApp1Project1
                -WebApp1Project1.csproj
            /WebApp1Project2
                -WebApp1Project1.csproj
            ...
         ...     
    /CodeSigningKey
        -KeyPair.snk
    /ReferencedAssemblies
        /Manufacturer1
            -Manufacturer1Assembly1.dll
            ...
        ...

The common libraries can still be added as project references in the server and client solutions. I've introduced a few new folders for common items such as the code signing key and 3rd party assemblies that are referenced (such as the Enterprise Library).

On top of that you'll want to employ a branching strategy of some kind to keep Main, Dev and Release code branches separate. I recommend a little light reading of the ALM Rangers branching guide on codeplex for that. http://vsarbranchingguide.codeplex.com/releases