Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

Using C#, Visual Studio 2010.

There is a namespace called System.Web.Mvc documented on MSDN. The documentation for all the types in that namespace says that they are in System.Web.Mvc.dll .

However, when I go to Add Reference, “.NET” tab, this assembly is missing from the list. Why?

Can you clarify: does your project WORK without that reference? Is it in your web.config (see my answer)? – Basic Sep 6, 2010 at 0:26 I am not working on any project. I just wanted to help someone here on StackOverflow. I usually add a reference in order to look at the IntelliSense and/or the F12 for any type. In this case the desired assembly was missing from the list, so I asked why. – Timwi Sep 6, 2010 at 0:34 NOTE to readers of this page - as of today (2015-02-09) the method for resolving this has changed over time - read all the answers - various version of VS.NET and .NET framework move the code referenced for MVC around into to different places. – qxotk Feb 9, 2016 at 19:41 I've got to admit this is the right way to add reference to MVC in most cases (it should spare you the problems with running the app outside of Visual Studio that bad references might cause). However in big solutions which already containing MVC some projects, using the "Manage NuGet Packages for solution" to install the same version of the library is even better. The reason is, if you just install them from NuGet package manager, you might end up with version incompatibility (the manager will usually offer you the newest version). – jahu Feb 10, 2015 at 10:54 I've used that solution for a project using MVC 4 that couldn't compile with Visual Studio 2015. It also ensures that the project libraries are uniform across all developpers. – ceetheman Dec 4, 2015 at 18:50 I had this problem with a box that had only VS2015 on it, while other team members had VS2013 - which might have them referencing the old location (no build errors) while I didn't have the code and build errors. Of Note, as of today, I could not find Microsoft.Web.Mvc - which were the references that caused the issue. In the answer from @forderah sheds the light on the fact that the name is different in NuGet. Microsoft.Web.Mvc is now Microsoft.AspNet.Mvc, which also pulls in the dependencies listed in his/her answer. – qxotk Feb 9, 2016 at 19:36 I even had this problem in VS2017, and this fixed it. Not sure why VS2017 told me that it thinks that the assembly that needs to be referenced is System.Web.Mvc while it's actually looking for Microsoft.AspNet.Mvc – Michael Davidson Jun 5, 2018 at 13:48 I'd go one step further and say you need to Manage Packages for the Solution . If you right-click on a Project and Select " Manage NuGet Packages... " then it will only be for that Project. If you right-click the Solution and Select " Manage NuGet Packages for Solution... " then you will see what Packages are Installed for All Projects within the Solution - along with which Version . In our case we had a mix of Different Version Numbers and Packages that were Not Installed in Projects where they were Referenced. From here we Installed " Microsoft.AspNet.Mvc " (by MS). – MikeTeeVee Feb 8, 2022 at 18:44 +1 for you because you found the root cause of the problem I had. I chose to use the NuGet install method proscribed below, and I will comment there what I did. – qxotk Feb 9, 2016 at 19:30 I tried this method in Visual Studio Community 2015 but I got a runtime error related to version incompatibility ( Could not load file or assembly...The located assembly's manifest definition does not match the assembly reference ). I have another project in my solution referencing a different version, and this method only allowed me to add a reference to System.Web.Mvc, Version=4.0.0.0. The NuGet install method added the correct version – NJS Aug 20, 2019 at 19:18

I had the same issue and wasn't able to locate the System.Web.MVC reference assembly.

Finally found out and it was located inside the following location.

Note if your VS was installed in C: (Sometimes the MVC.dll is not in the default location which everybody talk about, i mean the " Reference Assemblies " folder located in the C: drive.)

if its not there, it should definitely be in here:

\Program Files (x86)\Microsoft ASP.NET\ASP.NET MVC 2\Assemblies\System.Web.Mvc.dll

So add the dll through navigating or the browse tab in the add reference menu.

This get the reference for me, though I'm sure I've previously added this reference through the Framework Assemblies list. – Zarepheth Mar 26, 2013 at 19:32 Not really good solution if you work in a team with VCS. Absolute paths are evil in this case. – Denis The Menace Oct 16, 2014 at 9:21 Definitely agree that this is a bad solution in any kind of team development environment because of the hard-coded absolute path dependency. – Craig Tullis Feb 3, 2015 at 23:19 The way you get around that is to ensure everyone is using the same path for the DLL. It shouldn't be a problem if all team members have the assemblies installed at that location, as they should. Alternatively, the DLL can be copied from that path, and placed directly into the project, so it has a relative path. But either way, just having the location of where that DLL is, is a good starting point. – vapcguy Aug 21, 2018 at 20:10

You can also add this from the Nuget Package Manager Console, something like:

Install-Package Microsoft.AspNet.Mvc -Version 4.0.20710.0 -ProjectName XXXXX
Microsoft.AspNet.Mvc has dependencies on:
'Microsoft.AspNet.WebPages (≥ 2.0.20710.0 && < 2.1)'
'Microsoft.Web.Infrastructure (≥ 1.0.0.0)'
'Microsoft.AspNet.Razor (≥ 2.0.20710.0 && < 2.1)'
...which seems like no biggie to me.  In our case, this is a class library that exists solely to provide support for our Mvc apps.  So, we figure it's a benign dependency at worst.  
I definitely prefer this to pointing to an assembly on the file system or in the GAC, since updating the package in the future will likely be a lot less painful than experiences I've had with the GAC and file system assembly references in the past.
                I used this method, and I agree with not using local absolute paths in the references.  I used the NuGet package manager, adding the package and dependencies fixed the issue on my VS2015-only box.
– qxotk
                Feb 9, 2016 at 19:38
I have had the same problem and here is the funny reason: My guess is that you expect System.Web.Mvc to be located under System.Web in the list. But the list is not alphabetical.
First sort the list and then look near the System.Web.
                Also make sure that you are getting the correct version. In my case System.Web.Mvc v2 and v4 are there, and they too are not next to each other.
– TTT
                Apr 10, 2013 at 23:00
                Had same problem finding System.Web.Mvc for same reasons.  I went with Microsoft.AspNet.Mvc instead, ensuring to check to see what the other projects in my solution were using in regard to version number.
– qxotk
                Feb 9, 2016 at 19:39
                @Timwi I figured, but given the other answer, that there is v. little chance that its not there with vs 2010 installed and that in my case I always have found what I need in the references list without ever hitting the name header I had to say it ...  in fact, I now know why I never had to before and in vs 2010 I do - see the first comment: weblogs.asp.net/scottgu/archive/2009/10/29/…
– eglasius
                Sep 6, 2010 at 16:06
                So are you saying that clicking the Name header sorts things for you? Does nothing here on my machine...
– Roman Starkov
                Sep 8, 2010 at 8:37
Check MVC is installed properly.
Check the project's property and see what is the project Target Framework. If the target framework is not set to .Net Framework 4, set it.
Note: if target framework is set to .Net Framework 4 Client Profile, it will not list MVC reference on references list. You can find different between .Net Framework 4 and .Net Framework 4 Client Profile here. 
  
The .NET Framework 4 Client Profile is a subset of the .NET Framework 4 that is optimized for client applications. It provides functionality for most client applications, including Windows Presentation Foundation (WPF), Windows Forms, Windows Communication Foundation (WCF), and ClickOnce features. This enables faster deployment and a smaller install package for applications that target the .NET Framework 4 Client Profile.
                This was a good tip.  When I went to my project's properties, it only listed .NET Core 1 and 2. No .NET Framework 4.x.  I was missing assemblies in my list. Turns out it was how I built my project - I chose the wrong option - to use .NET Core instead of .NET Framework. Now I know the difference. :)
– vapcguy
                Aug 21, 2018 at 20:47
The desired assembly has appeared in the list now.
I can only speculate what caused it to appear, but I suspect it is the fact that I went File → New → Project → ASP.NET Web Application, which I had never done before. It is possible that this caused some sort of late initialisation to happen and the list to be populated with additional assemblies for Web development.
                it was always surely always there, its ok :P ... see the comment I added to my answer, in the link it says: "The issue with the .net tab, is while the async is happening and its being refreshed, its not sorting in alphabetical order..." ... which is a new behavior to vs 2010, I never realized that until I saw your question.
– eglasius
                Sep 6, 2010 at 16:10
                @egl I just tested on my machine here (VS2010) and it's not in the list at all. I do get different sets of assemblies depending on Target Framework, but this one is never there.
– Roman Starkov
                Sep 7, 2010 at 12:18
                @romkyns try targeting .net 4, and doing what I mentioned in my answer. Also make sure to give it enough time to load, since it does an async load.
– eglasius
                Sep 7, 2010 at 17:01
This has changed for Visual Studio 2012 (I know the original question says VS2010, but the title will still hit on searches).
When you create a VS2012 MVC project, the system.web.mvc is placed in the packages folder which is peer to the solution.  This will be referenced in the web project by default and you can find the exact path there).
If you want to reference this in a secondary project (say a supporting .dll with filters or other attributes), then you can reference it from there.
I didn't get System.Web.Mvc in VS 2012 but I got it in VS 2013.
Using AddReference Dialog,
Or, You can find this in your project path,
YourProjectName\packages\Microsoft.AspNet.Mvc.5.0.0\lib\net45\System.Web.Mvc.dll
I believe you'll find the MVC assembly is referenced in the web.config file, not in the project itself.
Something like this:
<compilation debug="true" targetFramework="4.0">
  <assemblies>
    <add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
    <add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
    <add assembly="System.Web.Mvc, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
  </assemblies>
</compilation>
To respond to your comment;
The best answer I can give is from here:
  
The add element adds an assembly
  reference to use during compilation of
  a dynamic resource. ASP.NET
  automatically links this assembly to
  the resource when compiling each code
  module.
it can be installed separated,
and it's not included in framwork,
choose tab list "extensions" and it exists there are and more other libs,
all is ok not needed to used old libs etc,
exists old 20 30 and 4001
If you got this problem in Visual Studio 2017, chances are you're working with an MVC 4 project created in a previous version of VS with a reference hint path pointing to C:\Program Files (x86)\Microsoft ASP.NET. Visual Studio 2017 does not install this directory anymore.
We usually solve this by installing a copy of Visual Studio 2015 alongside our 2017 instance, and that installs the necessary libraries in the above path. Then we update all the references in the affected projects and we're good to go.