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.UPDATEI own FinalBuilder.  I am  new to using it and do not know if it can benefit this process.
Strategy for maintaining assembly references in TFS
version control;team foundation server
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.aspxDecoupling 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. 