C#
Could not load file or assembly SystemWebHttp 400 after update from 2012 to 2013
Encountering the dreaded “Could not load file or assembly ‘System.Web.Http 4.0.0’ after update from 2012 to 2013” error can be a significant roadblock for .NET developers. This specific assembly, core to ASP.NET Web API functionality, often becomes problematic during framework or package upgrades due to versioning conflicts. When you transition an existing project, especially one originating from an older Visual Studio or .NET Framework version (like migrating from a 2012 environment to a 2013-era setup), the underlying dependencies can become misaligned. This guide will meticulously break down the causes of this common assembly loading failure and provide a clear, actionable roadmap to diagnose and resolve it, ensuring your application gets back on track.
Understanding the “Could not load file or assembly…” Error
The “Could not load file or assembly” error is a classic symptom of .NET’s dependency resolution mechanism failing to locate or load a required component. In this specific case, System.Web.Http 4.0.0 refers to a particular version of the ASP.NET Web API assembly. Web API, a framework for building HTTP services, relies heavily on specific versions of its core components. When your application tries to load an assembly, the .NET runtime performs a lookup based on the assembly’s name, version, culture, and public key token.
If the runtime cannot find an exact match for the requested assembly or encounters a mismatch between the version it expects and the version available, this error is thrown. This is especially prevalent during upgrades because newer NuGet packages or framework versions might depend on a different version of System.Web.Http than what your project’s existing references or other installed packages expect. Essentially, your application is asking for version 4.0.0, but the system either can’t find it or finds a different, incompatible version.
The Role of Assembly Binding
Assembly binding is the process by which the .NET runtime locates and loads the correct version of an assembly required by an application. When an application is compiled, it often records the specific versions of dependent assemblies it expects. However, sometimes newer versions of these dependencies become available, or other components in your application require a different version. This is where assembly binding redirects come into play. They act as instructions within your application’s configuration file (web.config or app.config) that tell the runtime: “If you’re looking for version X of this assembly, use version Y instead.” Without proper redirects, especially after an upgrade, the runtime might fail to load the correct assembly, leading to the “Could not load file or assembly ‘System.Web.Http 4.0.0’” issue.
.NET Framework and API Versioning
The transition from a 2012 development environment to a 2013-era one often implies an underlying shift in the .NET Framework version, for instance, from .NET 4.0 to .NET 4.5 or 4.5.1. While .NET Framework versions generally aim for backward compatibility, the evolution of packages like ASP.NET Web API (which often ships as NuGet packages separate from the core framework) can introduce breaking changes or new dependencies. Version 4.0.0 of System.Web.Http was typically associated with earlier iterations of Web API 1 or 2, which might have different internal dependencies or expectations compared to what a newer .NET Framework version or other updated packages might demand. This version mismatch is a key culprit.
Common Causes After an Upgrade
Upgrading a project, especially one with a long history or many third-party dependencies, is a common scenario for encountering assembly load errors. The shift from a 2012 development setup to a 2013-era environment often involves updating Visual Studio, the .NET Framework, and potentially numerous NuGet packages. This process, while beneficial for leveraging new features and security updates, can easily lead to a dependency conflict if not managed carefully.
Here are the primary reasons you might face the “Could not load file or assembly ‘System.Web.Http 4.0.0’” error post-upgrade:
-
Missing or Incorrect Assembly Binding Redirects: This is arguably the most frequent cause. When an update brings in a newer version of
System.Web.Http(e.g., 5.x.x), but parts of your application or other dependent libraries are still compiled against or expecting version 4.0.0, you need a binding redirect in yourweb.configto tell the runtime to use the newer version in place of the older one. Without it, the runtime fails to find 4.0.0 and throws an error. -
NuGet Package Version Conflicts: Your project might have multiple NuGet packages, each with its own dependency chain. An upgrade could bring in a new package that depends on a later version of
System.Web.Http, while another existing package explicitly depends on 4.0.0. NuGet tries to resolve these, but sometimes it results in an inconsistent state, leading to Question & Answer :
I did the upgrade according to. http://www.asp.net/mvc/tutorials/mvc-5/how-to-upgrade-an-aspnet-mvc-4-and-web-api-project-to-aspnet-mvc-5-and-web-api-2I get the error. Does any one else got this error?
Server Error in ‘/’ Application.
Could not load file or assembly ‘System.Web.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.Exception Details: System.IO.FileLoadException: Could not load file or assembly ‘System.Web.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Source Error:
Line 48: Line 49: Line 50: } Line 51: Line 52: protected void Application_BeginRequest(object sender, EventArgs e)
Source File: d:\SM\7.4Test\WebAPIServerV2\ThirdPartyWebAPI\Global.asax.cs Line: 50
Assembly Load Trace: The following information can be helpful to determine why the assembly ‘System.Web.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ could not be loaded.
=== Pre-bind state information === LOG: DisplayName = System.Web.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 (Fully-specified) LOG: Appbase = file:///D:/SM/7.4Test/WebAPIServerV2/ThirdPartyWebAPI/ LOG: Initial PrivatePath = D:\SM\7.4Test\WebAPIServerV2\ThirdPartyWebAPI\bin Calling assembly : ThirdPartyWebAPI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. === LOG: This bind starts in default load context. LOG: Using application configuration file: D:\SM\7.4Test\WebAPIServerV2\ThirdPartyWebAPI\web.config LOG: Using host configuration file: C:\Users\michalc\Documents\IISExpress\config\aspnet.config LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config. LOG: Post-policy reference: System.Web.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/9184b2ea/c6d4b139/System.Web.Http.DLL. LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/9184b2ea/c6d4b139/System.Web.Http/System.Web.Http.DLL. LOG: Attempting download of new URL file:///D:/SM/7.4Test/WebAPIServerV2/ThirdPartyWebAPI/bin/System.Web.Http.DLL. WRN: Comparing the assembly name resulted in the mismatch: Major Version ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Stack Trace:
[FileLoadException: Could not load file or assembly ‘System.Web.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)] ThirdPartyWebAPI.WebApiApplication.Application_Start() in d:\SM\7.4Test\WebAPIServerV2\ThirdPartyWebAPI\Global.asax.cs:50
[HttpException (0x80004005): Could not load file or assembly ‘System.Web.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app) +9935033
System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +118
System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +172
System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +336
System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +296[HttpException (0x80004005): Could not load file or assembly ‘System.Web.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +9913572 System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +101 System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +254
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.18408
I fixed this by reinstalling the NuGet package, which corrects broken dependencies. From the package manager, run:
Update-Package Microsoft.AspNet.WebApi -reinstall