TFS and shared projects in multiple solutions

Question

Our .NET team works on projects for our company that fall into distinct categories. Some are internal web apps, some are external (publicly facing) web apps, we also have internal Windows applications for our corporate office users, and Windows Forms apps for our retail locations (stores). Of course, because we hate code reuse, we have a ton of code that is shared among the different applications. Currently we're using SVN as our source control, and we've got our repository laid out like this:

 - = folder, | = Visual Studio Solution
-SVN
   - Internet
      | Ourcompany.com
      | Oursecondcompany.com
   - Intranet
      | UniformOrdering website
      | MessageCenter website
   - Shared
      | ErrorLoggingModule
      | RegularExpressionGenerator
      | Anti-Xss
      | OrgChartModule etc...

So..

The OurCompany.com solution in the Internet folder would have a website project, and it would also include the ErrorLoggingModule, RegularExpressionGenerator, and Anti-Xss projects from the shared directory.

Similarly, our UniformOrdering website solution would have each of these projects included in the solution as well.

We prefer to have a project reference to a .dll reference because, first of all, if we need to add or fix a function in the ErrorLoggingModule while working on the OurCompany.com website, it's right there. Also, this allows us to build each solution and see if changes to shared code break any other applications. This should work well on a build server as well if I'm correct.

In SVN, there is no problem with this. SVN and Visual Studio aren't tied together in the way TFS's source control is. We never figured out how to work this type of structure in TFS when we were using it, because in TFS, the TFS project was always tied to a Visual Studio Solution. The Source Code repository was a child of the TFS Project, so if we wanted to do this, we had to duplicate the Shared code in each TFS project's source code repository. As my co-worker put it, this "breaks every known best practice about code reuse and simplicity". It was enough of a deal breaker for us that we switched to SVN.

Now, however, we're faced with truly fixing our development processes, and the Application Lifecycle Management of TFS is pretty close to exactly what we want, and how we want to work. Our one sticking point is the shared code issue.

We're evaluating other commercial and open source solutions, but since we're already paying for TFS with our MSDN Subscriptions, and TFS is pretty much exactly what we want, we'd REALLY like to find a way around this issue.

Has anybody else faced this and come up with a solution?

If you've seen an article or posting on this that you can share with me, that would help as well.

As always, I'm open to answers like "You're looking at it all wrong, bonehead, HERE'S the way it SHOULD be done.

Answer 1

I think there's some misunderstandings here. First, you can have multiple (as many as you want) solutions in a single TFS project. Also, a single Visual Studio project can have any number of solutions referring to it.

Second, what version of TFS are you using? 2010 is different from 2005/08 in how it handles TFS projects.

Under 2008, there are several ways to approach this depending on what you want to get out of it. You can either have multiple TFS projects or a single TFS project.

I'll start with multiple.

Set up a TFS project for your shared library type code, and others for each regular project you have. As part of the development process on this shared library, check in the completed assemblies. Then Branch those assemblies into any other TFS project you want to use them in. When you do a feature update or bug fix to the shared library, simply merge the branch into any other TFS project you want the updates to go into.

This allows you to make shared changes for a single app without having to push all of them.

If you want a single TFS project holding everything, just add folders for each Visual Studio project you want. The visual studio solutions can refer back to projects outside of their base tree without issue. Now, when configuring things like Builds for each solution, make sure you limit what directory the build server pulls from / watches. That way you don't have it building one of your internal sites when changes were made to an external site.

Answer 2

Only recording this in the hope that it helps someone else some day, I fear I'm a little too late to answer your original question ;) We have a very similar situation, and your question (and subsequent answers) made it very easy for us to set up TFS properly.

To use your example to explain our setup:

# = Project Collection, > = Team Project, | = VS project
# SVN
    > Internet
        | OurCompany
        | OurCompany2
    > Intranet
        | UniformOrdering
        | MessageCentre
    > Shared
        | ErrorLogging
        | RegularExpression

This means that work can be assigned (using Scrum templates in Sharepoint) to any of the Team Projects (which are SAAS apps in our case) and the developer can choose to open any or all of the VS Projects to get the job done.

The majority of the senior developers (those that are across multiple products) have one VS Solution (maybe "WholeEnterprise.sln" to continue the analogy) that contains ALL the different VS Projects and can therefore work on any/all of them at any one time. We can also ensure that projects build properly, and all the dependencies are up to date before pushing an update.

The structure of this in your operating system of choice is totally up to you! Some of us have replicated the structure of TFS, others have a totally flat hierarchy... This doesn't seem to make a difference at the end of the day.