Introduction

If your project complains about System.Web.Http, Version=5.0.0.0, you are usually looking for the NuGet package that contains that assembly, not for a package literally named System.Web.Http. In classic ASP.NET Web API projects, that package is usually Microsoft.AspNet.WebApi.Core. The confusion comes from the fact that assembly names and NuGet package names are related but not identical.

Core Sections

The Package You Usually Need

For Web API 2 era .NET Framework applications, the targeted package is:

Install-Package Microsoft.AspNet.WebApi.Core -Version 5.0.0

If you want the broader package set, use:

Install-Package Microsoft.AspNet.WebApi -Version 5.0.0

Microsoft.AspNet.WebApi.Core gives you the assembly directly. The broader package is useful if you want related Web API components aligned at the same version.

Why Searching by Assembly Name Is Misleading

NuGet packages are distribution units. Assemblies are runtime artifacts inside those packages. That means:

• package name: Microsoft.AspNet.WebApi.Core
• assembly inside it: System.Web.Http.dll
• runtime identity: System.Web.Http, Version=5.0.0.0

So the assembly named in an exception is often not the literal package name you should search for.

Verify the Upgrade in Project Files

In older packages.config projects, you should see something like:

<package id="Microsoft.AspNet.WebApi.Core" version="5.0.0" targetFramework="net45" />

And the project reference may point to:

<Reference Include="System.Web.Http, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <HintPath>..\\packages\\Microsoft.AspNet.WebApi.Core.5.0.0\\lib\\net45\\System.Web.Http.dll</HintPath>
</Reference>

If the package installs successfully but the project still loads an older DLL, stale references are often the cause.

Binding Redirects Still Matter

For older .NET Framework applications, upgrading the package may not be enough. You may also need a binding redirect in web.config or app.config:

1<runtime>
2  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
3    <dependentAssembly>
4      <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
5      <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
6    </dependentAssembly>
7  </assemblyBinding>
8</runtime>

Without that, the application may restore and build but still fail at runtime when the CLR resolves assemblies.

Keep Related Packages Consistent

Web API package families often move together. If you upgrade only one package, you may introduce version drift between:

• 'Microsoft.AspNet.WebApi.Core'
• 'Microsoft.AspNet.WebApi.Client'
• 'Microsoft.AspNet.WebApi.WebHost'
• formatting-related packages

A safer upgrade is to review the whole Web API package set instead of changing one reference in isolation.

Visual Studio and CLI Options

You can install with Package Manager Console:

Install-Package Microsoft.AspNet.WebApi.Core -Version 5.0.0

Or with NuGet CLI:

nuget install Microsoft.AspNet.WebApi.Core -Version 5.0.0

CLI use is helpful in automation or when you want to inspect package contents outside Visual Studio.

How to Confirm the Assembly Is Really There

After install, inspect the package contents on disk:

dir .\\packages\\Microsoft.AspNet.WebApi.Core.5.0.0\\lib\\net45

You should see System.Web.Http.dll. That confirms you have the package that contains the assembly your application is asking for.

Scope of This Advice

This guidance applies to classic ASP.NET Web API on .NET Framework. It does not apply to ASP.NET Core, which uses a different HTTP stack and package structure entirely.

If the project is being modernized, do not assume a direct package-for-package upgrade path exists between classic Web API and modern ASP.NET Core.

Common Pitfalls

• Searching NuGet for System.Web.Http and assuming no solution exists when that package name does not appear.
• Upgrading one Web API package while leaving the rest of the stack on incompatible versions.
• Ignoring binding redirects in older .NET Framework applications.
• Leaving stale assembly references in the project after the package upgrade.
• Applying this guidance to ASP.NET Core, where the package model is different.

Summary

• The usual package behind System.Web.Http, Version=5.0.0.0 is Microsoft.AspNet.WebApi.Core.
• Assembly names and package names are not the same thing, so search by the Web API package family.
• Check project references, package metadata, and package contents after upgrading.
• Add or update binding redirects when classic .NET Framework runtime resolution requires it.
• Keep related Web API packages aligned to avoid version conflicts.