Home/ Questions/Q 60137
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T18:06:53+00:00

In our environment we have a Lib folder which contains various third party assemblies

  • 0

In our environment we have a Lib folder which contains various third party assemblies referenced by our projects. For example, Enterprise Libary and Elmah.

Sometimes a dev doesn’t do a get latest on that folder. When the dev then loads a project which can’t find the assembly in the expected folder, Visual Studio automatically locates another copy and updates the project references.

The problem occurs when the dev checks in the project and it screws everyone else up.

Is there a way to stop visual studio 2008 from doing this?

UPDATE: I wanted to add that we are using TFS for source control.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Here’s how we guard against that at my company. (Your mileage will vary!)

    Any non-system (or otherwise non-GAC) references come from our dev server, which every developer has mapped to their W: drive. We have a common DLL directory, with subdirectories by client (or vendor), and further subdirectories as appropriate. No DLLs are ever stored in source control, except license.dll as needed by Infragistics occasionally.

    For vendor-provided libraries (EntLib, Infragistics, etc.), as policy we reference from the W: drive. Period. No one is authorized to reference from anywhere else. This codes the Hint in the project files to a common path.

    For in-house libraries (client and internal projects), our continuous integration process outputs the DLLs into the appropriate branch of this directory — again, where all our references come from.

    This does slow down our local compile time (for local debugging), as VS will auto-refresh these against the server every time. It’s an annoyance (sometimes a project may take 5 or 6 minutes to build locally), but it’s a necessary evil to work around people using different references. The advantage here is that as soon as someone checks in code for one of those references, the CI server kicks off a build and everyone gets it pretty darned quickly.

    The trick to this is a stable, repeatable build process and a continuous integration server. We’re using CruiseControl.NET, integrated with NAnt builds, but insert your favorite CI server and build tool here.

    So far we’ve had zero issues as a result of this process, except when the build server kicks in while our source control system (also known as the Demon Spawn, see so many of my recent remarks) performs a large multi-file check-in. (As Demon Spawn doesn’t support transacted check-ins.) However, this is a very rare occurrence — perhaps once every 5 or 6 weeks. And a force rebuild immediately afterward takes care of it.

    Just some thoughts … This technique should keep people from screwing up your source control — and as an added bonus, reduce the size of your source control as you won’t be checking in DLLs, just dll.refresh files.

    • 0