none
How to properly reference class libraries from other team projects?

    Question

  • Class Libraries (Team Project)

     - Main

     --- Source

     ----- ClassLibrary1

     ----- ClassLibrary2

     

    ProductA (Team Project)

     - $Beta

     --- Source

     ----- ProductA

     - Releases

     --- 1

     ----- $1 (Branch of Beta)

     ----- $2 (Branch of Beta)

     

    If I add a project reference to any of the class library projects from within ProductA, and then branch Beta to 1.1, all of the project references break.

     

    How do I properly add project references to a different team project that will not break when I branch to any folder depth?


    Tuesday, March 29, 2011 12:55 AM

All replies

  • Your options basically amount to:

    1. Move $/Beta/Source down one level so everything has the same depth
    2. Use different workspace mappings for different branches, such that local copies have the same relative path even if the server paths don't
    3. Add some MSBuild mojo to your root makefile(s) so that there's another layer of indirection in the properties/items that make up your @ReferenceDirs
    4. Invert the folder structure so that ClassLibrary1 is underneath $/Beta/Source, etc

    I prefer #4.  A branch should be self-contained.  Everything works much nicer when you can tell TFS "Get $/some/branch" and know you'll end up with everything you need to build, deploy, and test the app.  

    It's also better for configuration management.  Ongoing development of ClassLibrary1 can still happen in another branch -- or even another team project -- without affecting the stability of your builds.  You decide when to admit new (potentially breaking) changes into your project.  Depending on the way your teams interoperate this might be infrequent, regular, or automated; you might share at the source code level, or just accept their binaries (often necessary with 3rd party libs); you might be an intermediate stop in a broader flow of changes across the company, or just a passive consumer (a leaf node in the Branch Hierarchy viewer, if you will).  It's totally flexible...all without having to worry about annoying stuff like "what is the relative path inside their project?"

    Tuesday, March 29, 2011 2:29 AM
  • I'd love the #4 option too, but TFS doesn't allow nested branches.

    The only way I know how to make #4 to work is to manually copy over changes. We used to do that but switched to source control so we wouldn't have to anymore.

     

    I have team projects like ProductB, ProductC, etc, that all reference class libraries.

     

    We want to reference the class library projects, and not just their outputs, because each product team does actively develop one or more of the class libraries that almost all of our products reference.

    From a developer standpoint, working in a class library, then compiling it, then having to merge the dll into ProductA->Source->Shared->Class Libraries, then having to open up ProductA to see how the new change works just seems wrong.

    Tuesday, March 29, 2011 2:43 AM
  • >> each product team does actively develop one or more of the class libraries that almost all of our products reference

    This strikes me as a good thing, not a hindrance, if #4 appeals to you.  Since so much of your coding is collaborative, why not make every branch a superset?  

    Adding "extra" products to a branch that'll never change there is quite inexpensive, at least for TFS.  If the total size of a branch becomes too much for your client workstations to handle (in terms of download time, disk space, and/or recompile time) then you can cloak the products you don't need...  Though it's a good idea for some workspaces (e.g. the ones on the build server) to still maintain a complete copy, so that you can quickly see if any of your changes have inadvertently broken another product.

    Tuesday, March 29, 2011 4:14 AM
  • I'm not sure how that is accomplished. Can you map out a simple folder structure please?

    Note that we have at least 4 team projects:

    Class Libraries

    ProductA

    ProductB

    ProductC

     

    If I understand it correctly, to do that I would need to have all of our projects under one team project. The reason we have separate team projects is to better isolate the teams that work on their own code sets, permissions, bug tracking, etc..

    Tuesday, March 29, 2011 4:40 AM
  • Ok, I've gone over 3 scenarios on how to do this:

     

    Scenario 1
    Products reference class libraries using direct project references.
    When a product is branched to a different folder depth, project references break.
    This does allow the easy manipulation of the class libraries while inside of the Product solutions speeding up development dramatically.

    Class Libraries (Team Project)
    -- Main
    ---- Source
    ------ ClassLibrary1
    ------ ClassLibrary2

    ProductA (Team Project)
    -- Main (Branch)
    ---- Source
    ------ ProductA
    -- Releases
    ---- 1
    ------ 1 (Branched from Main)

     

    Scenario 2
    Products reference compiled class libraries from a folder inside if its own branch.
    Branching does not break references.
    Simultaneous development of class libraries and products is very slow and cumbersome.

    Class Libraries (Team Project)
    -- Main
    ---- Source
    ------ ClassLibrary1
    ------ ClassLibrary2

    ProductA (Team Project)
    -- Main (Branch)
    ---- Source
    ------ ProductA
    ------ Shared
    -------- Class Libraries (Compiled class libraries are put in here)
    -- Releases
    ---- 1
    ------ 1 (Branched from Main)

     

    Scenario 3
    Products reference class libraries using direct project references.
    Branching does not break references.
    This does allow the easy manipulation of the class libraries while inside of the Product solutions speeding up development dramatically.

    Class Libraries (Team Project)
    -- Main
    ---- Source
    ------ ClassLibrary1 (Branch)
    ------ ClassLibrary2 (Branch)

    ProductA (Team Project)
    -- Main
    ---- ProductA (Branch)
    ------ Source
    -------- ProductA
    ---- ClassLibrary1 (Branched from Class Libraries)
    ---- ClassLibrary2 (Branched from Class Libraries)
    -- Releases
    ---- 1
    ------ 1
    -------- ProductA (Branched from Main)
    -------- ClassLibrary1 (Branched from Main)
    -------- ClassLibrary2 (Branched from Main)

     

    Scenario 3 is the best I could come up with. It involves extra merging to distribute changes to other tools but seems to be the easiest way to actively develop class libraries and products simultaneously.

     

    I'm open to feedback!

    Wednesday, March 30, 2011 1:46 AM
  • Ok, I've gone over 3 scenarios on how to do this:

    ...

    .....

     

    Scenario 3

    ...

    ..

    I'm having the same problem as well.  See: http://stackoverflow.com/questions/5720661/tfs-2010-branch-across-team-projects-practices

    We are currently doing Scenario 3 for our branching with /releases and /dev but as you stated, it becomes insanely repetitive and annoying to branch/merge.

    Wednesday, April 20, 2011 1:46 PM
  • We're still using scenario 3. It does complicate the branching/merging, but it allows us to completely isolate development with no risk of breaking public releases, etc..

     

    We're happy with this method.

    Saturday, April 23, 2011 12:31 AM
  • I'm having problems trying to figure out how to do the Workspace mapping. I'm basically doing Scenario 2 (our common Class Libraries are not modified by other teams, only the team that owns them, so I only need to branch the DLLs). But how can I structure the workspaces such that I can branch between the Team Projects?

    In your scenario, I would have two different workspaces, one for the $/ClassLibraries Team Project and one for the $/ProductA Team Project. But creating a third all-encompassing workspace so that I can branch the ClassLibrary DLLs into ProductA doesn't seem to be working out too well, because those local folders are already mapped by the first two workspaces.

    Any suggestions?


    ~~Bonnie Berent [C# MVP]

    geek-goddess-bonnie.blogspot.com
    Wednesday, April 27, 2011 1:50 AM
  • I'm very new to these topic but for me it seems to be the best to make the "superset". see also http://blogs.msdn.com/b/jmeier/archive/2007/03/15/multiple-solutions-and-flat-projects.aspx

    -Main
    ---ClassLibrary1
    ---ClassLibrary2
    ---Product1
    ---ProductN
    ---product1.sln
    ---product2.sln

    If you want to make a (feature) Branch, you branch the complete Main line (including all folders and files).

    there is a nice article how to branch using scrum. But you can easily adapt these strategy if you replace "Sprint" with "Feature".
     http://blog.hinshelwood.com/guidance-a-branching-strategy-for-scrum-teams/#

    you may also take a look at http://branchingguidance.codeplex.com/ 

    Thursday, March 29, 2012 12:53 PM