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.

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

  • "This isn't always a good idea or feasible". Not saying that you're wrong, but what makes you say this? If you have code that's being actively worked on, it should be referenced as a project reference. – nlawalker Mar 7 '12 at 3:00
  • @nlawalker - In cases where project A in solution A depends on project B, yet project B is not being actively worked on while in solution A. – P.Brian.Mackey Mar 7 '12 at 13:48
  • 1
    Don't look at solutions as units of developer work, look at them as units of build. If Project A in Solution A depends on project B, and project B is actively being worked on by anybody, make it a project reference. If the guy working on Proj. A doesn't need to work on Proj. B, then he doesn't need to touch it. – nlawalker Mar 7 '12 at 17:18

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


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.

  • AFAIK Nuget is not too corporate friendly. MSBuild we are talking CI which we aren't quite ready for, maybe soon though. – P.Brian.Mackey Mar 7 '12 at 13:49
  • 1
    Why is Nuget not corp friendly? You can host your own package gallery on your own share and keep it within the intranet. – Nick Nieslanik Mar 7 '12 at 15:06
  • Also, you indicate that you are talking about MSBuild/CI and aren't ready. FYI - If you use Visual Studio, you are already using MSBuild so it's pretty trivial to use it in a CI environment. Why aren't you ready for CI? – Nick Nieslanik Mar 7 '12 at 15:08
  • Writing MSBuild by hand is not something I consider an easy task. The CI server in TFS helps create these tasks. We don't have any time to set one up, admin it, and learn how to integrate it at this time. – P.Brian.Mackey Mar 7 '12 at 15:18
  • 1
    Well, I don't think there's a "quick fix" out there that will be your silver bullet. Build/Release management done correctly is hard and it takes time, resources and a team commitment to make it work. – Nick Nieslanik Mar 7 '12 at 15:28

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">

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.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.