I just solved the following error:
System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
Strange thing - it only seemed to be a problem when I made a release build although was a little intermittent - I could create a debug build and the issue could sometimes temporarily go away.
Turned out that I had an enterprise library dll in the project Microsoft.Practices.EnterpriseLibrary.Data.dll that wasn't being used, was version 5.0.505.0, and looks like it was trying to pull in v. 5.0.505.0 of Microsoft.Practices.EnterpriseLibrary.Common, when v. 5.0.414.0 of this 'Common' dll was already in the project. Didn't pin down why this was mainly happening in release mode.
Something that would've helped to track this down and clearly identify the cause would have been to find out for certain which dll is pulling another dll into my Visual Studio project? I want to be able to go from the dll that's causing the problem, and see what dll is including it. This answer:
Find out why Visual Studio decides to copy DLLs into a bin directory
says that ildasm or reflector can be used, but what do you need to look for using these tools and how? I've Googled this but didn't see anything.
As a side note, any ideas on why switching to release mode would cause my issue? I've wondered if doing this caused Visual Studio to attempt to pull a release version of Microsoft.Practices.EnterpriseLibrary.Common from somewhere and it's the wrong version, but this makes no sense to me as this is a '3rd party' (Microsoft) library that is already in release mode, it doesn't explain the intermittency, and I don't see why switching an individual project to release mode would affect a reference to an external library.