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" />"

“GatherAllFilesToPublish” Error in VS2010 Project Upgraded to VS2012

PROBLEM: After upgrading a VS2010 web forms project to VS2012, when I went to publish the project I received this error "The target "GatherAllFilesToPublish" does not exist in the project.".

SOLUTION: For me I simply unloaded the project, edited the project file to change this line:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

to this:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

After saving and reloading the project file the upgrade wizard automagically kicked in and did some magic and the publish started working.  

Aftewards I went in and had a look at the project file again and it seemed the upgrade wizard added a PropertyGroup element with VisualStudioVersion and VSToolsParth sub-elements (similar to what this guy recommended manually adding but for me manually adding them didn't work - <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />)

You'll also find lots of links about renaming Microsoft.WebApplication.targets and running a repair (http://stackoverflow.com/questions/10989051/why-do-i-get-the-error-the-target-gatherallfilestopublish-does-not-exist) - which I tried but this didn't fix the issue.

Cannot merge branches due to "incompatible pending change" error

PROBLEM: Merging two branches in TFS2012 and it fails saying there are 0 errors but X warnings - refer to Output window for details. When you check the Output window you see:

"TF203015: The item $/XXX/YYY has an incompatible pending change"

SOLUTION: In my case, it was because the file in the changeset I wanted to merge (web.config) had pending changes in the target branch which had been added to "Excluded Changes".  In my case I moved the file to "Included Changes" and Checked In the changeset (so the server knew). Then I was able to merge my two branches.  I think if I had discarded my changes on the target branch for that file it would have potentially resulted in the same effect.  Some other googling showed that sometimes people had this issue due to file permissions but that wasn't the issue in my case. That's a few hours of my life I'll never get back!