Solved

TFS Source Control Folder Structure

Posted on 2014-02-19
8
2,237 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 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
How Do You Stack Up Against Your Peers?

With today’s modern enterprise so dependent on digital infrastructures, the impact of major incidents has increased dramatically. Grab the report now to gain insight into how your organization ranks against your peers and learn best-in-class strategies to resolve incidents.

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

Creating Instructional Tutorials  

For Any Use & On Any Platform

Contextual Guidance at the moment of need helps your employees/users adopt software o& achieve even the most complex tasks instantly. Boost knowledge retention, software adoption & employee engagement with easy solution.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

This document covers how to connect to SQL Server and browse its contents.  It is meant for those new to Visual Studio and/or working with Microsoft SQL Server.  It is not a guide to building SQL Server database connections in your code.  This is mo…
After several hours of googling I could not gather any information on this topic. There are several ways of controlling the USB port connected to any storage device. The best example of that is by changing the registry value of "HKEY_LOCAL_MACHINE\S…
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…
Attackers love to prey on accounts that have privileges. Reducing privileged accounts and protecting privileged accounts therefore is paramount. Users, groups, and service accounts need to be protected to help protect the entire Active Directory …

734 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