Solved

TFS Source Control Folder Structure

Posted on 2014-02-19
8
1,897 Views
Last Modified: 2014-02-20
Dear Experts,

I have a question on maintaining Visual Studio project dependencies in source control.

This is how I have my projects and solutions set up in TFS.

TFS Structure:
$Team Project1 -> Main -> Sources -> MainApp (Contains MainApp.Sln) -> MainProject (Contains MainApp.csproj and other files)

$Team Project1 -> Main -> Sources -> CommonLib (Contains CommonLib.sln) -> CommonLibProj (Contains CommonLibProj.csproj and other files)

In other words, both MainApp and CommonLib are two independent folders under $Team Project1 -> Main -> Sources folder.

The MainApp.csproj is a c# windows forms application that has an assembly reference to CommonLib.csproj which is a class library project.

Local Folder Structure is similar:
C:\Main\Sources\MainApp

C:\Main\Sources\CommonLib

Each solution compiles fine locally.

When I added a build definition to build MainApp solution, it failed. Based on the build error message, it seems that since TFS build has no knowledge of the other project, it could not find the CommonLib project and so it failed. So I modified the build definition to build both solutions (build the common library first). And the result is that build succeeded.

My questions are:
1.      Did the build succeed because the source settings in the build definition include mappings of source control folders of both solutions to build agent folders?
2.      Is this complaint with source control folder structure practices?

I’d like to keep this solution structure because it looks fairly simple unless I am violating any recommended good practices.

I am using TFS 2012 and Visual Studio 2012.

Thanks for your help.
0
Comment
Question by:shekhar_shashi
  • 4
  • 3
8 Comments
 
LVL 96

Assisted Solution

by:Bob Learned
Bob Learned earned 150 total points
ID: 39873293
Here is what I would do...create independent folders, but branch in the common folder to a Shared Source folder.  Assembly references are relative to the project folder.  Then, if you branch again, or use a CI Build Definition, the files will be under a common folder, and the relative paths will still work.  

Example branching hierarchy:

Development
        20140220-Optimization
              Shared Binaries
              Shared Source
              Source
Main
        Shared Binaries
        Shared Source
        Source
Release
        v1.0.0.0
        v1.1.0.0
0
 
LVL 21

Accepted Solution

by:
Craig Wagner earned 350 total points
ID: 39873656
Step #1, don't use assembly references when you own the code. It will only leave you in a world of hurt (as you're already finding out). This has also been a long-standing recommendation from Microsoft.

In the most simple terms a solution (in Visual Studio speak) should be all the projects it takes to make up an application (the main exe, any supporting libraries, etc.). Because everything should be in the same solution project references should be used. That allows Visual Studio to track dependencies, build things in the correct order, ensure version numbers match, and so on.

An approach that I've been using for years quite successfully is to put "applications" and "libraries" into separate hierarchies and, if branching is necessary, branch both. This keeps relative paths consistent across the source control system and local dev boxes.

applications
    app1 <- sln for app1 goes here
        app1 proj1
        app1 proj2
    app2 <- sln for app2 goes here
        app2 proj

libraries
    lib1
    lib2
    lib3

The "application" solutions include all application-specific projects and any library projects that that application requires with project references between dependencies.
0
 
LVL 3

Author Comment

by:shekhar_shashi
ID: 39874187
Thank you @TheLearnedOne and @CraigWagner for the excellent explanations. Let me re-state what you just explained to make sure I understood this right.

1. If I had a class library and an application that is dependent on the class library, I could keep them in folders at the same level but branch the class library to something like a 'shared folder' under application solution. That way I'll reference the common class library by project and my CI build will just build just need the application solution path.

2. I am guessing that the changes made to the library will be merged from the class library folder to the 'shared folder'.

My concern with this approach is - if I branched out the main application branch to lets say main application-dev, wont this be a case of 'nested branching' not allowed by TFS?

Can you provide an example of a branching on a scenario like mine? In your examples, I am not able to understand where the branched out 'shared folder' would reside under a branch that comes out of app1 or app2.

Thanks for your help.
0
 
LVL 3

Author Comment

by:shekhar_shashi
ID: 39874269
In the nested branching scenario I described above, I changed the source control folders to use the following hierarchy,

$TFSProject -> Main -> Sources -> CommonLibrary (CommonLibrary.sln here) -> CommonLibraryProject (.csproj and other files here)

$TFSProject -> Main -> Sources -> App1 (app1.sln here) -> App1Project (.csproj and other files here)

I branched out CommonLibraryProject folder to 'Shared Source' folder under App1Project folder.

My CI build that is meant only for App1 references only App1 solution and it works fine.

When I tried to branch out App1 to App1-Dev, I got TF203071 error. So I converted the Shared Source branch to a folder. TFS now allows me to merge from CommonLibraryProject to the Shared Source folder under app1. Does this appear like an acceptable approach?
0
6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

 
LVL 21

Expert Comment

by:Craig Wagner
ID: 39874488
I'll admit I didn't entirely follow your posts, so I may be being redundant here.

One thing I left out is that "applications" and "libraries" have a common root folder.

trunk
  applications
    app1 <- sln for app1 goes here
        app1 proj1
        app1 proj2
    app2 <- sln for app2 goes here
        app2 proj

  libraries
    lib1
    lib2
    lib3

When we create a branch for development we simply branch from "trunk."

v1.0
  applications
    app1 <- sln for app1 goes here
        app1 proj1
        app1 proj2
    app2 <- sln for app2 goes here
        app2 proj

  libraries
    lib1
    lib2
    lib3

It keeps the branching/merging operations very simple, everything branches from trunk and everything merges back to trunk.

HTH
0
 
LVL 3

Author Comment

by:shekhar_shashi
ID: 39874629
Thanks for the clarification. My concern with branching at trunk level is that I will eventually have about 25 independent applications. So branching out "that high' will make the merging difficult because I'll have changes from 25 applications to merge back into the main branch. So I am trying to branch out at application level but still make the common libraries available to applications if needed. As per requirements, the libraries may be referenced by one or more of the applications. So lets assume app1 is dependent on lib1.

So if I branch out trunk/libraries/lib1 to a folder under app1, my solution now looks like Trunk/Applications/App1/Common/Lib1. I have a solution structure that builds fine for app1.

Now lets take this a step further and consider the scenario where I want to branch out from app1. I will be trying to create a branch (like app1-dev) that contains a branch (from lib1) under it (like trunk/applications/app1-dev/common/lib1).

So what I am trying to create looks like this:

trunk/applications/app1-dev which contains (new branch)

trunk/applications/app1-dev/common/lib1 (already a branch)

This type of nested branching is apparently not allowed by TFS.

So I converted the trunk/app1/common/lib1 to a folder. Now my merges work fine. I can make changes in trunk/libraries/lib1 and merge those to trunk/app1/common/lib1.

I was concerned with branching at trunk level because I have large number of independent applications in source control. May be branching at trunk level is still the best approach but I am trying to confirm if there are any concerns with this approach of branching at application level. I will have teams focused only on one or two applications and it would be nice if they merged changes at application level.

Thanks again for the great explanations and patience.
0
 
LVL 21

Assisted Solution

by:Craig Wagner
Craig Wagner earned 350 total points
ID: 39874683
I understand your concern. My previous employer used the multi-solution approach like I outlined, My current employer has every application in a single solution so branching at the trunk makes sense.

I believe what we did at my previous employer (it's been a few years) is we would branch the application(s) that a project needed and then branch the entire "libraries" folder into the same location. The big thing to remember is that you need to keep the relative folder structure from trunk in the branch so that all of the references still line up.
0
 
LVL 3

Author Comment

by:shekhar_shashi
ID: 39874757
Thanks for the update. It seems like the following rules should be considered when setting up source control folders for applications with dependencies.

1. Project references are preferred over assembly references.
2. Set up your folder structure and branching approach based on your organization's requirements but try to keep your folder structure as flat as possible.
3. Visual Studio projects maintain relative reference paths to other Visual Studio projects they are dependent on. Make sure those reference paths line up when branching.
4. Branch only if you need isolation.

http://msdn.microsoft.com/en-us/magazine/gg598921.aspx

The 'Source Code Sharing' section is very important. Even though it discusses sharing across TFS projects, it is still applicable to multiple applications in the same TFS project. Thanks a bunch for your help.
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

In my previous two articles we discussed Binary Serialization (http://www.experts-exchange.com/A_4362.html) and XML Serialization (http://www.experts-exchange.com/A_4425.html). In this article we will try to know more about SOAP (Simple Object Acces…
A long time ago (May 2011), I have written an article showing you how to create a DLL using Visual Studio 2005 to be hosted in SQL Server 2005. That was valid at that time and it is still valid if you are still using these versions. You can still re…
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…
When you create an app prototype with Adobe XD, you can insert system screens -- sharing or Control Center, for example -- with just a few clicks. This video shows you how. You can take the full course on Experts Exchange at http://bit.ly/XDcourse.

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now