This project has moved. For the latest updates, please go here.

Sharing code across Team Projects, concerning binary assets

Apr 21, 2011 at 5:24 PM

Hello, and many thanks to this group for the guidance that they've published. I'm just getting my first exposure to TFS, and it has all been very helpful.

Our company was recently acquired, and as part of the "integration", we will be migrating our SCM from CVS to TFS2010.  Previously, our source code structure was very simple, but mostly inflexible.  NEW COMPANY has some loose guidelines that we need to follow, but there is a particular area where I haven't been able to nail down a good answer.

It has to do with common source libraries that are shared across projects.  Given the following structure:

$/FirstApplication/
  Main/
    Src/
      FirstApp/
        Src/
          FirstAppWeb/
          FirstAppSpecificClassLibrary/
      SharedBinaries/
        logger.dll

$/SecondApplication/
  Main/
    Src/
      SecondApp/
        Src/
          SecondAppWeb/
          SecondAppSpecificClassLibrary/
      SharedBinaries/
        logger.dll

$/CommonClassLibraries/
  Main/
    Src/
      CommonClassLibrary1/
        Src/
          CommonClassLibrary1/ <--VS project is here
      CommonClassLibrary2/
        Src/
          CommonClassLibrary2/ <--VS project is here
      SharedBinaries/
        SpecialFunctions.dll

Let's say that I want to use CommonClassLibrary1 in both FirstApp and SecondApp. My plan would be to branch something like:

$/CommonClassLibraries/Main/Src/CommonClassLibrary1 ->$/FirstApplication/Main/Src/Firstapp/Src/Common/CommonClassLibrary1

and

$/CommonClassLibraries/Main/Src/CommonClassLibrary1 ->$/FirstApplication/Main/Src/Secondapp/Src/Common/CommonClassLibrary1

First of all, as a TFS infant, is this structure sensible? It seems like I could still use the relative path that CommonClassLibrary1 has for SpecialFunctions.dll and make sure that SpecialFunctions.dll is copied into the SharedBinaries directory for Firstapp and Secondapp.

However, what if the different CommonClassLibraries are or are not related for any business reason? Is it better to have each CommonClassLibary contain its own subdirectory of binary references? Something like:

$/CommonClassLibraries/
  Main/
    Src/
      CommonClassLibrary1/
        Src/
          CommonClassLibrary1/ <--VS project is here
        Binaries/
          SpecialFunctions.dll
      CommonClassLibrary2/
        Src/
          CommonClassLibrary2/ <--VS project is here
        Binaries/
          SpecialFunctions.dll

But this seems like a lot more effort to track.

Hope I didn't ramble too much. I'm just trying to use this migration as an opportunity to get rid of some less-than-best practices that we were guilty of.

Thanks!

Mark