Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
"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
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
up vote 3 down vote accepted

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

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.

share|improve this answer
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
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
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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