Source control - How to version resources that are shared across projects

Question

We use Team Foundation Server and have numerous ASP.NET Web Application Projects. Each of the Web Apps uses a custom content management system that we've developed in house. The CMS is itself, an ASP.NET web app.

When deployed, the CMS resides in a subdirectory, such as "/Admin". The CMS is comprised of .aspx and ascx files, and the corresponding assemblies are, of course, placed in the bin.

Presently, the CMS files exist separately for each Web App in source control. In other words, an "Admin" folder exists in each web application that depends on the CMS. This poses obvious challenges since updates to the CMS must be distributed to every dependent site. It's my job to automate/simplify the process.

We currently do not perform any automated builds. I have limited knowledge of source control branching in TFS and I'm not sure that it's applicable in this scenario. What is the best way to ensure that dependent projects receive the latest assemblies and markup from the CMS project? Thanks in advance.

It sounds like #2 (from 'bamboo) is the solution I'm after. Given that the shared code already resides in each individual project, can you briefly describe the process that I'll go through to "Branch/Share" the CMS? Also, it's worth noting that I do not want the .cs files propogated to the dependent projects, just the markup and assemblies. Does this change the strategy? Should I first create a build event on the shared project to copy the requisite files to a "Release" folder, and then branch the Release folder?

Answer 1

Not sure about TFS, but in most source control systems, you can share code across multiple locations. Changes to any shared copy are reflected across all. At the Visual Studio level, they will appear as independent pieces of code.

Each of your web apps (solutions) contains a project that is comprised entirely of the shared code. Typically the source code is shared and becomes part of the build process. You could share the resulting DLL, but most people do not source control DLLs.

If you don't have source to the shared parts, likely installing the code in the GAC becomes your only option to create a shared piece.

Answer 2

The are a couple popular ways to handle this scenario.

1) Map the TFS project for the shared stuff to each applications workspace and then include the shared project in each applications solution. Use this method if you want all teams/apps to get the shared changes immediately when they build since they will get latest of the shared stuff as well.

2) Branch/Share the shared stuff into each applications source control tree. This is easy to do in TFS. This is really good if each team/app wants to control when they get the latest of the shared stuff. This keeps the teams being able to do their thing until they are ready to integrate the shared stuff.

I generally always prefer #2. But it really depends on the specifics of how you need/want to work.

Answer 3

We have a shared library that is used with several of our projects. We then add a reference to the shared library, not the actual project...

You then have to add the referenced path to the build xml, so that your TFS server knows where the .dll is located. Each time a new build is done for the project it copies the most recent version of shared to the bin for the project.

All of our projects including Shared has 4 branches: Development, Integration, Staging, and Production. So when we need to make changes to our Shared library and we do it in its Development branch because its isolated. Once we are happy we merge our changes into integration. We build shared integration, and then we build what ever projects are affected by the change. This is when we start testing the other applications to see if our changes have caused any bugs. So...

1. One place to make our changes to shared library
2. Merger to a single branch, not multiple branches in each project.
3. Use of Shared is as easy as adding a reference
4. A single project and a version of Shared can be pushed from Development to Production without affecting any of the other projects. The .dll version of Shared is copied to the projects bin folder. Once changes on another project are being done it will get the most recent version when its pushed through its branches.