If you are maintaining legacy ASP.NET applications, few things are more frustrating than deploying your code and immediately hitting the “Yellow Screen of Death” (YSOD). One of the most common errors developers encounter when moving older projects to new servers is:
“Could not load file or assembly ‘System.Web.Mvc, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.”
While this error looks intimidating, it is almost always a configuration issue rather than a code bug. This guide will explain why this version mismatch occurs and provide three step-by-step solutions to get your application running again.
Understanding the Error: Why is System.Web.Mvc Missing?
This error occurs when your application is explicitly looking for Version 2.0.0.0 of the ASP.NET MVC framework, but it cannot find it in two key locations:
-
The Global Assembly Cache (GAC): The shared folder on the server where .NET assemblies are stored.
-
The Application Bin Folder: The local folder where your compiled application lives.
Why Version 2.0.0.0?ASP.NET MVC 2 was released around 2010. Modern servers and development environments typically have MVC 4, 5, or newer installed. When you deploy an old application that references the specific 2.0.0.0 DLL to a modern server that only has 5.0.0.0, the application crashes because the versions do not match.
Here are the three most effective ways to fix this.
Solution 1: Use Assembly Binding Redirects (Recommended)
The cleanest, most professional fix is to tell the .NET runtime: “If the app asks for Version 2.0.0.0, give it the newer version we actually have installed.” This is done via a Binding Redirect.
This method allows you to run legacy code without needing to downgrade your server’s libraries.
Steps to Fix:
-
Open your Web.config file in the root of your project.
-
Search for the
<runtime>configuration section. -
Inside
<assemblyBinding>, add a<dependentAssembly>entry forSystem.Web.Mvc.
Here is the code snippet to redirect all older versions (from 1.0.0.0 up to 5.2.7.0) to use the modern version you likely have installed (e.g., 5.2.7.0):
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-5.2.7.0" newVersion="5.2.7.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Pro Tip: To find the exact version you have installed, look at your References in Visual Studio, right-click System.Web.Mvc, select Properties, and check the Version field.
Solution 2: The “Copy Local” Fix
If you are unable to edit the Web.config or if you strictly require the legacy behavior of MVC 2, you can force Visual Studio to include the DLL file in your deployment package. This ensures the DLL travels with your app, so it doesn’t matter what is installed on the server.
Steps to Fix:
-
Open your solution in Visual Studio.
-
In the Solution Explorer, expand the References tree.
-
Right-click on System.Web.Mvc.
-
Select Properties.
-
Locate the property Copy Local and set it to True.
-
Rebuild your solution.
After rebuilding, check your project’s /bin folder. You should see the System.Web.Mvc.dll file there. When you publish your application next time, this file will be uploaded to the server, resolving the “file not found” error.
Solution 3: Reinstall via NuGet (The Upgrade Path)
If the assembly is missing entirely from your references (indicated by a yellow warning triangle in Visual Studio), your project definition might be corrupted, or the reference path is broken.
The best long-term SEO and performance strategy for your app is to upgrade to a supported version of MVC using NuGet.
Steps to Fix:
-
In Visual Studio, go to Tools > NuGet Package Manager > Package Manager Console.
-
Run the following command to reinstall the latest supported MVC version:
Install-Package Microsoft.AspNet.Mvc
This command will download the correct libraries, update your References automatically, and often add the necessary binding redirects to your web.config for you.
Summary: Which Fix Should You Choose?
-
Choose Solution 1 (Binding Redirects) if you have a newer version of MVC on the server and want your old app to use it. This is the standard enterprise solution.
-
Choose Solution 2 (Copy Local) if you are in a rush and just need to get the specific DLL onto the server without changing configuration files.
-
Choose Solution 3 (NuGet) if your project references are broken or if you are ready to modernize the application.
By ensuring your System.Web.Mvc references align with your server environment, you eliminate the version mismatch and ensure a stable deployment.
Javier is Content Specialist and also .NET developer. He writes helpful guides and articles, assist with other marketing and .NET community work
