I have an MVC project thats been working perfectly until I updated my machine a week ago. I now receive a Binding Error when trying to run the project
Managed Debuggin
Instead of changing the framework files, try adding this to the web.config file:
<system.web>
<httpRuntime targetFramework="4.5" />
<compilation debug="true" targetFramework="4.5" >
<assemblies>
<remove assembly="Microsoft.VisualStudio.Web.PageInspector.Loader,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</assemblies>
</compilation>
...
</system.web>
i've observed this happening on a machine with Visual Studio 2013 installed.
it began happening, as best I can tell, after the VS2013 update 4.
(it may have occurred previously, but this is new for my environment)
I located this assembly in the GAC (two versions, one for VS2012, the other for VS2013) but these versions are strong named (obviously) with a version of "12.3.0.0" (take note the above resolution error is for a version "14" assembly.)
Here is the call stack for the first instance of this particular exception:
mscorlib.dll!System.Reflection.RuntimeAssembly.nLoad(System.Reflection.AssemblyName fileName, string codeBase, System.Security.Policy.Evidence assemblySecurity, System.Reflection.RuntimeAssembly locationHint, ref System.Threading.StackCrawlMark stackMark, System.IntPtr pPrivHostBinder, bool throwOnFileNotFound, bool forIntrospection, bool suppressSecurityChecks) + 0x23 bytes
mscorlib.dll!System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(System.Reflection.AssemblyName assemblyRef, System.Security.Policy.Evidence assemblySecurity, System.Reflection.RuntimeAssembly reqAssembly, ref System.Threading.StackCrawlMark stackMark, System.IntPtr pPrivHostBinder, bool throwOnFileNotFound, bool forIntrospection, bool suppressSecurityChecks) + 0x99 bytes
mscorlib.dll!System.Reflection.Assembly.Load(System.Reflection.AssemblyName assemblyRef) + 0x25 bytes
Microsoft.VisualStudio.Web.PageInspector.Loader.dll!Microsoft.VisualStudio.Web.PageInspector.Runtime.Loader.RuntimeLoader.GetRuntimeAssembly(out System.Reflection.Assembly runtime) + 0xdb bytes
Microsoft.VisualStudio.Web.PageInspector.Loader.dll!Microsoft.VisualStudio.Web.PageInspector.Runtime.Loader.RuntimeLoader.LoadRuntime() + 0x2a bytes
Microsoft.VisualStudio.Web.PageInspector.Loader.dll!Microsoft.VisualStudio.Web.PageInspector.Runtime.Loader.RuntimeLoader.PreApplicationStart() + 0x27 bytes
[Native to Managed Transition]
System.Web.dll!System.Web.Compilation.BuildManager.InvokePreStartInitMethodsCore(System.Collections.Generic.ICollection<System.Reflection.MethodInfo> methods, System.Func<System.IDisposable> setHostingEnvironmentCultures) + 0x142 bytes
System.Web.dll!System.Web.Compilation.BuildManager.InvokePreStartInitMethods(System.Collections.Generic.ICollection<System.Reflection.MethodInfo> methods) + 0x5a bytes
System.Web.dll!System.Web.Compilation.BuildManager.CallPreStartInitMethods(string preStartInitListPath, out bool isRefAssemblyLoaded) + 0x67 bytes
System.Web.dll!System.Web.Compilation.BuildManager.ExecutePreAppStart() + 0x9a bytes
System.Web.dll!System.Web.Hosting.HostingEnvironment.Initialize(System.Web.Hosting.ApplicationManager appManager, System.Web.Hosting.IApplicationHost appHost, System.Web.Configuration.IConfigMapPathFactory configMapPathFactory, System.Web.Hosting.HostingEnvironmentParameters hostingParameters, System.Security.Policy.PolicyLevel policyLevel, System.Exception appDomainCreationException) + 0x20a bytes
System.Web.dll!System.Web.Hosting.HostingEnvironment.Initialize(System.Web.Hosting.ApplicationManager appManager, System.Web.Hosting.IApplicationHost appHost, System.Web.Configuration.IConfigMapPathFactory configMapPathFactory, System.Web.Hosting.HostingEnvironmentParameters hostingParameters, System.Security.Policy.PolicyLevel policyLevel) + 0x16 bytes
[Appdomain Transition]
System.Web.dll!System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironment(string appId, System.Web.Hosting.IApplicationHost appHost, System.Web.Hosting.HostingEnvironmentParameters hostingParameters) + 0x12f3 bytes
System.Web.dll!System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironmentAndReportErrors(string appId, System.Web.Hosting.IApplicationHost appHost, System.Web.Hosting.HostingEnvironmentParameters hostingParameters) + 0x25 bytes
System.Web.dll!System.Web.Hosting.ApplicationManager.GetAppDomainWithHostingEnvironment(string appId, System.Web.Hosting.IApplicationHost appHost, System.Web.Hosting.HostingEnvironmentParameters hostingParameters) + 0x6c bytes
System.Web.dll!System.Web.Hosting.ApplicationManager.CreateObjectInternal(string appId, System.Type type, System.Web.Hosting.IApplicationHost appHost, bool failIfExists, System.Web.Hosting.HostingEnvironmentParameters hostingParameters) + 0x4d bytes
System.Web.dll!System.Web.Hosting.ProcessHost.StartApplication(string appId, string appPath, out object runtimeInterface) + 0x18f bytes
[Native to Managed Transition]
This suggests the problem is Microsoft's (and not something I've done in, say, an assembly, application nor machine config.)
I spot-checked all of my configs (literally, all, my project's web.config as well as all .NET runtime machine configs, all versions/platforms) and I could not find a reference to this assembly anywhere.
To work around this mistake (which Microsoft needs to address) I've added an assembly binding redirect, as follows, to my web.config (NOT my machine configs):
<dependentAssembly>
<assemblyIdentity name="Microsoft.VisualStudio.Web.PageInspector.Runtime" publicKeyToken="b03f5f7f11d50a3a" />
<bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="12.3.0.0" />
</dependentAssembly>
This suggests Microsoft released a build of Visual Studio, or similar, which is binding against a future, unreleased version of these assemblies.
Hope this helps someone else out there!
We encountered a similar problem by deploying assemblies generated by ASP.NET from a developer machine to a production environment (referring to assemblies generated for .ascx and .aspx controls which are compiled at runtime).
We are (hackishly) copying and persisting such runtime generated assemblies from ASP.NET temporary compile folders (ie. "C:/Users/[USER]/AppData/Local/Temp/Temporary ASP.NET Files/") to avoid some recompiling as the service boots, in order to improve performance. However using assemblies compiled on a dev machine introduces dependencies to VisualStudio assemblies.
We fixed it by letting the production environment generate these assemblies on its own. We are copying and persisting these 'production' assemblies instead and the problem vanishes entirely.
Make sure you are not doing such awkward use of ASP.NET generated assemblies and it will probably fix it.
If you uncheck Thrown Exceptions in the exception options it should stop prompting you. I'm guessing it is part of its normal operation. I've noticed the same thing.