Strategy for maintaining assembly references in TFS

Question

I have a 3 branch setup: Dev, QA, Prod. There is a references folder where we store common 3rd party and internal assemblies. Change mgmnt has been challenging. Sometimes Devs forget to go into the References folder and check in the new version.

We tried referencing Projects, which results in a reference to the bin folder. This works out fine as long as you keep the build order correct and always contain all the projects in the same solution file. This isn't always a good idea or feasible, so we went to a references folder.

Continuous Integration may help alleviate some of these issues, but we don't have a CI server yet. Is there a good process for for managing the References folder that doesn't require so much manuel dev intervention?

I thought about copying the files out on post-build. That doesn't solve the issue of checking the new version in so other devs can access it.

We have TFS. This is for internal corporate development. Anything that requires open-source of our product is not possible.

UPDATE
I own FinalBuilder. I am new to using it and do not know if it can benefit this process.

Answer 1

I think you have a couple of things here to consider.

1 - If your source tree is reasonably complex, then I'd encourage you to separate your solution files from your build system and build the *proj MSBuild files directly using recommendations from Microsoft such as MSBuild Traversal projects (see this article for more information on this best practice

http://msdn.microsoft.com/en-us/magazine/dd483291.aspx

Decoupling the solution file from the build system allows you the ability to keep tight control over the build system, leverage Project References where they make sense and still allow developers the ability to use solutions at will as a productivity option. If a dev adds a new project, there's a conscious decision to include it at the appropriate location in the build process. Furthermore, you can use the MSBuild "BuildProjectReferences" property to indicate if MSBuild should auto-build Project references or use existing output.

2 - Nuget... http://nuget.org/

Using a package management system such as Nuget to host and deploy your 3rd party dependencies can eliminate them from source control and allow you to publish new versions and create new Nuget packages at will. There's been a pretty large adoption rate for Nuget of late and the resulting internet documentation should help you decide whether to host your own Nuget server, use the public one, or skip it altogether.

Having said all of this, and regardless of whether or not either of these solutions sound good to you, I'd definitely encourage you to get a CI build running ASAP. It's invaluable in enforcing quality and getting a team in the habit of following protocol. In fact, if you are having issues getting quality up after standing up a CI build, I'd encourage you to use a Gated-Checkin build (part of TFS for free) to ensure stuff builds correctly prior to check-in.

If you choose to keep your dependency tree checked into source control, then I'd suggest that you a) separate internal dependencies from 3rd party ones and b) keep the dependency folder branch-specific so you can build against different dependency sets based on branch easily.

Answer 2

What has worked best for us is to make sure we all have identical workspaces with the same local folder structure. Then the references can use relative file paths in the project file. I.E. in the dev Project1 project file you'd see something like:

<Reference Include="Project2">
    <HintPath>..\..\..\Project2_Dev\Project2\bin\Release\Project2.dll</HintPath>
</Reference>`

The projects are not in the same solution but this works for everyone because we have the same folder structure. This eliminates the need to store and update the assemblies in TFS. You only need to get latest on Project2 and build it.

The cons to this are:

• To build Project1, you have to also have all of the referenced projects locally and they must also be able to build. This can get tedious at times if you have chain of dependencies across several projects. It has also been a pain in cases where we give a contractor access to Project1 but don't want to set them up with all of the other projects. In this case we have either just created the empty folder structure for them and placed only the prebuilt dll in the bin, or temporarily used a shared Assemblies folder like you described in the question.
• When you merge, TFS wants to make the project files match each other so it will try to overwrite the relative paths in the project file. This is especially a problem for me since upgrading to VS 2013 because it no longer asks which version I want to keep. It just automatically chooses one. So before checking in, I have to manually undo the changes to those lines in the csproj files (which is what brought me to this question hoping to find a solution for.)