Could not load file or assembly or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

PROBLEM: Received the below error at runtime:

{"Could not load file or assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)":"Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed"}

SOLUTION: Lots of potential answers here: http://stackoverflow.com/questions/22507189/could-not-load-file-or-assembly-newtonsoft-json-version-4-5-0-0-culture-neutr

But for me the problem was I had a solution with multiple projects, each with different versions of the nuget package. Obviously only one version can be deployed and if it an old version that gets deployed a binding redirect isn't going to help - so in my case I had to upgrade each project to use the same version of the nuget package - note there is a new feature (which I didn't use) that can help manage one nuget package across multiple projects in a solution (https://artczernecki.wordpress.com/2015/09/08/consolidating-package-versions-with-visual-studio-2015-nuget-package-manager/ and http://stackoverflow.com/questions/34022454/nuget-consolidate-vs-update).

Note, this problem reared its head again briefly after I pulled a different branch via github... I think in that case it was an issue with Visual Studio cache files (*ResolveAssemblyReference.cache) found in the obj folder of the projects... closing the solution and re-starting Visual Studio was enough to refresh these and fix the issue.

INTERESTING SIDE NOTE: Nuget package versions are not necessarily the same as the dll AssemblyVersion (the important version - this is what the compiler cares about and is the version number that is important for binding redirects etc - can view in Visual Studio under properties where it is referenced or can use ILSpy or similar) or AssemblyFileVersion (what you see when you right click and view a DLLs properties in explorer - compiler never refers to this).  As an example... Newtonsoft.json nuget package 5.0.2 has a AssemblyVersion 4.5.0.0 and AssemblyFileVersion 5.0.2.16008 ... some more reading is here: http://stackoverflow.com/questions/64602/what-are-differences-between-assemblyversion-assemblyfileversion-and-assemblyin and http://stackoverflow.com/questions/11965924/nuspec-version-attribute-vs-assembly-version

ELMAH filtering of exceptions by type using the is-type assertion

PROBLEM: In one of our projects, validation errors are thrown as exceptions (ValidationException) - we obviously don't want to be notified about a user forgetting a mandatory field etc, and luckily ELMAH has support to filter out certain exceptions from being logged and/or emailed.  Have a read here: https://code.google.com/p/elmah/wiki/ErrorFiltering and here https://code.google.com/p/elmah/wiki/ErrorFilterExamples and here http://www.diaryofaninja.com/blog/2011/09/20/adding-filters-to-your-elmah-installation

I tried the following in the web.config and it resulted in a runtime error:

<errorFilter>
  <test>
    <is-type binding="BaseException" type="MyProject.Models.ValidationException" />
  </test>
</errorFilter>

SOLUTION:
You need to include the assembly name e.g.

<errorFilter>
  <test>
    <is-type binding="BaseException" type="MyProject.Models.ValidationException, MyProject" />
  </test>
</errorFilter>

(this isn't in the limited doco of ELMAH but the creator of ELMAH does mention it in a random forum post i.e. "In the type attribute of the is-type element, you forgot to specify the assembly where the CustomLibrary.CustomException type can be found. In absence of the assembly specification, ELMAH looks for the type in its own assembly. If your assembly name is the same as the namespace (i.e. CustomLibrary) then try changing the is-type element to read as follows: <is-type binding="Exception" type="CustomLibrary.CustomException, CustomLibrary" />"