BUG: VS2010 outsmarts itself and auto "fixes" references and breaks the build server!

Classic Problem: .NET project builds fine on local developers workstation but fails on the build server because the developer referenced DLL's that were in the GAC on their workstation but don't exist on the build server.

Classic (POOR) Solution #1: Install the files on the build server and add them to GAC. This "works" but it's a maintenance hassle and the build master may not want you to install obscure tool FooBar.dll on "his" build server.

Classic (BETTER) Solution #2: Create a lib directory (or whatever your local naming custom happens to be) in your source tree, copy FooBar.dll into the lib directory and change all of your references to point to the files in the lib folder instead of the GAC. Now the build server will get the dll's it needs from source control and your project should build happily. Problem Solved!

Insidious new VS2010 BUG (probably a "feature"): You try and solve the problem using Class Solution #2 above. You create a lib directory, you copy dll's into it, you delete the problem references, you recreate the problem references, you checkin your changes, and YOUR BUILD IS STILL BROKEN! WTF?

It turns out the Visual Studio 2010 believes it is smarter than you are! When you added your new reference by browsing to the dll, Visual Studio looked at the file and said "Ah ha!" is see the exact same dll in the GAC and I'll add the reference as a GAC reference instead because this stupid developer obviously doesn't understand the power and beauty that is the GAC!

Being an experienced .NET developer after several failed builds you smell a rat, and open the project file in notepad and see the following:

    <... stuff deleted for clarity ... />

    

    

    <... stuff deleted for clarity ... />
  

Now that dog don't hunt because System.Windows.Controls.Data.DataForm.Toolkit.dll and System.Windows.Controls.Toolkit.dll don't exist in the GAC on the build server.

You are SURE you changed both of those references to files references, and so you delete them and re-add them as file references again just to be sure. Same screwed up result...

And so now in frustration you manually edit the project file(s) like this (below) to create the file references that Visual Studio 2010 wouldn't let you create through the UI.

     <... stuff deleted for clarity ... />

    
      ..\lib\System.Windows.Controls.Data.DataForm.Toolkit.dll
    

    
      ..\lib\System.Windows.Controls.Toolkit.dll
    

     <... stuff deleted for clarity ... />
  

Success! Your solution builds on the build server!

And you are reminded yet again that GAC is evil...