We\'re having problems getting visual studio to pick up the latest version of a DLL from one of our projects.
We have multiple class library projects (e.g. Business
One possible reason is the Reference PATHs. If there's any reference to the old dll folder, VS will use it as the main reference, even though you added the new dll reference.
We (and, as the only .NET developer on our team, by that I mean I) had the exact same problem. I traced it down to a referenced dll, which in turn AGAIN references the dll suffering from versionitis. It seems that because I wasn't updating all the references which in turn reference the dll, it was replaced by an older version at some point during the build process.
One of the symptoms I experienced was that when I am in the code editor, the new class I added to the referenced project would be coloured appropriately, but when I hit Build, it changes back to black and I get a message saying the class does not exist (along with a very sarcastic "Ar you missing an assembly reference?"). This led me to believe that the problem has to happen during the Build phase.
I would therefore suggest building any and every other project that points to this DLL and re-add their references too.
Enable FusionLog and after the DLL fails to load, open the file with the DLL's name in the folder C:\FusionLog\Default\devenv.exe. This will show the path from where the DLL was really loaded.
In my case, an old version had mysteriously appeared in
C:\Program Files\Microsoft Visual Studio 10\Common7\IDE !
To stop this ever happening again, I added a security rule "Deny Write" to Everyone on Common7\IDE.
I had a problem similar to what is described here except that my solution to the problem had to do with how I was compiling the code. There is a difference between build, clean and Rebuild. In my case, I was just using a Build between my changes and the dll from the dependent solution were not being carried over with all the changes to the other solution where the reference was set. I solved it by using Rebuild which cleans, compiles and links all source files regardless of whether they changed or not. Then the dll from the the first solution was updated and copied over automatically to the 2nd solution where the reference was set and the problem was solved. Cheers, I hope this helps.
Similar symptoms - problem was in "Referene paths" in Project Properties, Reference.
Full descrtiption and solution here: Referenced assemblies automatically replaced by visual studio visual-studio/22810867#22810867
There are few options that you can try.