Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best practice to share projects between solution trees (MSVS 2008 & MSVS 2010)

We have 50+ projects divided into 2 solution trees managed by TFS (Version: Visual Studio 2008 / TFS RTM (9.0.21022.8)).

30+ projects are Visual Studio 2008 projects and others are Visual Studio 2010

New projects use some older assemblies via references to binaries.

During developing new projects we have to make changes into older assemblies so we have to keep 2 MSVS instances opened simultaneously.

Is there a way to share compilable sources with TFS between two different studios solution trees? Or shall we upgrade 2008 solution tree to 2010? Does TFS 2008 support shared projects (or may be it have to be upgraded too)?

Thank you in advance!

like image 233
Andrew Florko Avatar asked Aug 02 '10 05:08

Andrew Florko


1 Answers

Andrew:

First off, we violate a couple of "best practices" to accomplish this, but pragmatism is where best practice meets the real world.

What we do is this:

  1. All binaries are checked in to TFS within a LocalBin folder that consolidates all of our binaries.
  2. All shared assemblies are located within a folder called LocalBin/SharedBin
  3. The SharedBin folder is branched to a top-level SharedBin folder within the consuming team project(s).
  4. On a successful main build, the LocalBin/Sharedbin is merged to the projects' SharedBin folders.

It winds up being something like this:

$/ProjectA/Main/Localbin/SharedBin is branched to $/ProjectB/Main/SharedBin and $/ProjectB/Dev/Sharedbin (as well as the equivalent folders in $/ProjectC, $/ProjectD et cetera).

We only do this sharing when we have a successful MAIN build, and the build is responsible for merging not only to the other MAIN branch projects, but also to the DEV branch projects, so they are up to date.

We've toyed around with the idea of coping the binaries to a shared network location after successful build, and having a convention to reference those binaries in that network share, but this process is working well for us today, and we're loathe to make changes to it at this point (more important things happening for now).

This is one of those things that's hard to fully describe in a posting, so if you have further questions, I'd be happy to try to answer them.

BTW, our solution was built and is running under TFS2008 with thousands of project files, and likely millions of lines of code. It does increase the build time due to the merge and increases the amount of space used in your repository, but both have been manageable thus far.

like image 72
Robaticus Avatar answered Sep 27 '22 15:09

Robaticus