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

HTTP Error 404.17 when running WCF service in Visual Studio 2015 (VS2015)

PROBLEM: On Windows 7 with Visual Studio 2012 I could run an asp.net .NET 3.5 project with WCF services.  After installing Windows 10 and Visual Studio 2015, I could no longer debug a WCF service which previously ran fine on Windows 7 and Visual Studio 2012.  I get the following error: "

HTTP Error 404.17 - Not Found - The requested content appears to be script and will not be served by the static file handler. - Most likely causes: The request matched a wildcard mime map. The request is mapped to the static file handler. If there were different pre-conditions, the request will map to a different handler. Things you can try: If you want to serve this content as a static file, add an explicit MIME map."

SOLUTION: I had to turn on a number of Windows features that aren't on by default:

• .NET Framework 3.5 (includes .NET 2.0 and 3.0) > Windows Communication Foundation HTTP Activation
• .NET Framework 3.5 (includes .NET 2.0 and 3.0) > Windows Communication Foundation Non-HTTP Activation
• .NET Framework 4.6 Advanced Services > WCF Services > HTTP Activation (probably not required for my project but useful for the future)

I also ran this but I don't think I needed to / should have (http://ngeor.net/2011/07/iis-7-gives-404-17-error-with-svc-wcf-services/):

"%WINDIR%\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" –r

And then despite all this things didn't work, I had to manually update the IIS Express settings used by Visual Studio... WHICH are hidden away in a hidden folder in your solution e.g.

[PROJECT FOLDER]\.vs\config\applicationhost.config

I had to add the following to the section starting with <handlers accessPolicy="Read, Script">

<add name="xoml-64-ISAPI-2.0" path="*.xoml" verb="*" modules="IsapiModule" scriptProcessor="%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness64" />
<add name="rules-64-ISAPI-2.0" path="*.rules" verb="*" modules="IsapiModule" scriptProcessor="%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness64" />
<add name="svc-ISAPI-2.0-64" path="*.svc" verb="*" modules="IsapiModule" scriptProcessor="%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness64" />
<add name="xoml-ISAPI-2.0" path="*.xoml" verb="*" modules="IsapiModule" scriptProcessor="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
<add name="rules-ISAPI-2.0" path="*.rules" verb="*" modules="IsapiModule" scriptProcessor="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
<add name="svc-ISAPI-2.0" path="*.svc" verb="*" modules="IsapiModule" scriptProcessor="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv2.0,bitness32" />
<add name="xoml-Integrated" path="*.xoml" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode,runtimeVersionv2.0" />
<add name="rules-Integrated" path="*.rules" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode,runtimeVersionv2.0" />
<add name="svc-Integrated" path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode,runtimeVersionv2.0" />

There are lots of other similar applicationhost.config files but this is the one you need to update.

I thought that because of our source control branching approach that I'd need to manually update this anytime I create a new branch that needs WCF working BUT apparently there is a project file (not web.config) setting: UseGlobalApplicationHostFile, which you can set to true to just use the global setting (which is stored in Documents\IISExpress\config) http://stackoverflow.com/questions/32940080/visual-studio-2015-debugger-uses-local-applicationhost-config-instead-of-global and http://stackoverflow.com/questions/12946476/where-is-the-iis-express-configuration-metabase-file-found (that being said, I created a new branch the other day and hadn't yet set that setting or updated the Visual Studio applicationhost.config file and I was still able to debug the WCF services... go figure!