.Net Assembly Hell is what we've been calling it here. MS will never learn. Yes, we have gotten it to work by deleting all existing references in our projects and re-adding them. This is such a nightmare! We have several dozen projects. The problem would not be so nightmarish if we could some how write a utility to tell all of the projects to resynch with the current version. As I said before, we only have EXACTLY ONE copy of the assembly in the entire system. I guess there is no way to fix this. This is much worst than DLL hell. With DLL hell, users had the problems and developers can figure out how to quickly fix it on their machine. With .Net assembly hell, you have no clue, and it shows up every time.
With the copy local issues, I suspect it only helps with a separate issue that display similar symptoms. The one I am currently seeing refuses to fix itself after switching copy local to false and clicking the resynch button. It is ashame. They wanted to fix DLL hell and copy some of the ideas from Java, but they introduced a more hellish problem by trying to differentiate from the way Java does packages. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.