0

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

kamaci
  • 72,915
  • 69
  • 228
  • 366
lmttag
  • 2,499
  • 4
  • 26
  • 30
  • possible duplicate of [Help Structuring VS2010 Solutions/Projects and TFS2010](http://stackoverflow.com/questions/5083211/help-structuring-vs2010-solutions-projects-and-tfs2010) – John Saunders Feb 23 '11 at 01:45
  • This looks like a duplicate, not a follow-on. Please say why this is not a duplicate question. – John Saunders Feb 23 '11 at 01:46
  • The first post was asking about the information/examples provided in the Team Development with Visual Studio Team Foundation Server document. Just trying to understand what Microsoft was suggesting, as well as the other questions. This post is specifically about our current code base and how to structure it in the "best" way. Similar topics, but different. I didn't want to put it all into one post because it would have been very long and possibly confusing. That's why this post is a follow-on post. – lmttag Feb 23 '11 at 15:12
  • This has been asked before. http://stackoverflow.com/questions/4465919/project-directory-tree-on-tfs-2010 – LordHits Feb 23 '11 at 21:41
  • I am having a very difficult time understanding how this is substantially different from your previous question. When I say _substantially different_, I mean I don't see why the two can't be combined. – Tim Post Feb 24 '11 at 08:33

1 Answers1

0

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

daughey
  • 639
  • 5
  • 10