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.
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.
I aggree with with John on most points with the exception of putting your dlls in source control.
I usually have a ThirdParty folder which will then have vendor product and version breakdowns so, the ajax toolkit is stored in $/ThirdParty/Microsoft/AjaxToolkit/(some version number). I like this approach because we can put a label on all the artifacts that go into making a build.
Another idea might be to the dll's within the project so if they get the latest of the project they will get the dlls.
I don't think this is possible.
If you open a project file in a text editor you'll see that visual studio doesn't store hard references to assemblies but it stores a "HintPath" instead. If the reference isn't found there visual studio will automatically try the GAC.
It might be a good idea to set up a continuous integration server (if you don't already have one) this will act as an early warning system for situations like this.
Yes, this is ABSOLUTELY INSANE and is really painful. Here is another option for you:
1. Remove assemblies from GAC, as other posts suggested.
2. Have your dependency resolution system deliver assemblies to your BIN folder. This is where all your solution assemblies would also be compiled to.
3. Set all the references Copy Local = false AND Specific Version = False.
The point of this is to cause assembly loading exception when debugging, because if it is not in BIN then there is nothing to copy it there. AND your solutions will compile faster because VS will not have to copy files around. AND this will prevent "undead" dlls sitting somewhere in obj directory, which VS would miraculously find and copy around...
This works well on solutions that you control. We have been doing this for years. And it is very easy to figure out if something goes off track cause then you just go looking for an assembly with Copy Local = true or Specific Version = True, which happens once in a while (forget, tired, etc. ).
My current problem is that I do not control the structure or settings of the solution I am working on, and so looking for a solution for this ancient problem. I hoped that VS team solved it... Alas... Team, stop this pain.
