After Windows update "The type or namespace name 'Html' does not exist in the namespace 'System.Web.Mvc'"

Question

I did a Windows update and afterwards my asp.net mvc 5 application will no longer load complaining about

CS0234: The type or namespace name 'Html' does not exist in the namespace 'System.Web.Mvc'

indicating my views web.config is at fault

  <system.web.webPages.razor>
    <host factoryType="System.Web.Mvc.MvcWebRazorHostFactory, System.Web.Mvc, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
    <pages pageBaseType="System.Web.Mvc.WebViewPage">
      <namespaces>
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Optimization"/>
        <add namespace="System.Web.Routing" />
        <add namespace="Ogre.Extensions" />
        <add namespace="Newtonsoft.Json"/>
      </namespaces>
    </pages>
  </system.web.webPages.razor>

Now this is very confusing. In my project itself I can see the Html namespace, opening my assembly in ILSpy I can navigate to the bound System.Web.Mvc and I can it as well, and the fusion log is not showing any suspicious binding errors.

It's as if just my views are getting bound (successfully) to an old version of Mvc. Why would that ever happen? How can I fix it?

Let me be clear that there have been no configuration or even code changes. This is all on my dev machine on IISExpress. It was running, I did the update and rebooted and now it is no longer running.

Here are my recent installs from the update. I could start removing them one by one, but I want to know what is actually going wrong as it feels like I'm missing part of the story.

Solution 1

Holy crap, thanks to @Nevada-Williford for the hint. Going in and setting my System.Web.Mvc reference to <Private>True</Private> (Copy Local = True) fixed it. Note, that before the update everything was working, after the update I had to modify my csproj to get it working again.

Working theory on what's going on:

Copy Local = True and <Private>True</Private> used to be almost, but not exactly, the same thing. The former was a Visual Studio setting, the latter an msbuild setting. If the msbuild setting was absent, the Visual Studio setting would be applied (as long as you were in VS). In this update I think they changed it so Copy Local just reflects the presence attribute.

In our project we do not have that attribute set explicitly but Copy Local = True so prior to the update System.Web.Mvc.dll gets copied to the bin directory. After the update, since the attribute is missing Copy Local shows False and you have to set it to True to make sure you get a local copy.

Manually setting Copy Local = True (or adding that xml element to msbuild) fixes the issue.

Edit: While this appears to be the answer to the specific question, anyone coming here should read the comment thread and other answers - especially dmatson's - for more context, caveats, and related bugs.

Solution 2

This was broken for any users without CopyLocal=true (or, in MSBuild speak, <Private>True</Private>) by MS14-059. MVC templates do set <Private>True</Private> by default, but if you use NuGet to update the MVC version, you lose that setting (see NuGet bug #4344).

There are two aspects to the problem:

1. Razor doesn't include a reference to MVC by default, so its compilation won't work unless some version of the MVC DLL exists in your bin folder.
2. If you deploy to a separate machine that doesn't have this update installed, the MVC DLL isn't included in your output anymore, so MVC will be missing.

You're seeing problem #1. To resolve both problems, I'd recommend making both of the following changes:

1. Add the following configuration to Views\Web.config:

   <system.web>
     <compilation>
       <assemblies>
         <add assembly="System.Web.Mvc, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
       </assemblies>
     </compilation>
   </system.web>
   

2. Set CopyLocal=true in the VS UI for the project reference, or manually add the following line below in the Reference in your .csproj file:

   <Private>True</Private>
   

So your full reference should look something like the following:

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

Note that NuGet will remove the CopyLocal/Private setting if you update packages again in the future. (For example, if you update to MVC 5.2 today). If that version of MVC is ever GAC'd, problem #1 above will not recur as long as you've added the configuration in step A above, but problem #2 could still happen again. To ensure this doesn't happen in the future, I'd recommend manually setting CopyLocal back to true any time you do a NuGet package update.

Solution 3

1. You can go to References of current Project.
2. Right click in dll System.Web.Mvc and choose Properties
3. A Properties window will open
4. Change Copy Local to True

Solution 4

Setting CopyLocal=true did not help. Cleaning the solution then closing it and reopening it again worked. You might need to close the entire Visual Studio instance as well.

Solution 5

This appears to have been caused by a Windows Update (KB2990942) to fix security vulnerablity MS14-059, allowing security feature bypass. Our builds stopped working on our build server after the Windows Update was installed, and updating the csproj files to use 4.0.0.1 for the System.Web.Mvc reference fixed the issue.

Microsoft's description of the vulnerability is:

The vulnerability could allow security feature bypass if an attacker convinces a user to click a specially crafted link or to visit a webpage that contains specially crafted content designed to exploit the vulnerability. In a web-based attack scenario, an attacker could host a specially crafted website that is designed to exploit the vulnerability through a web browser, and then convince a user to view the website. The attacker could also take advantage of compromised websites and websites that accept or host user-provided content or advertisements. These websites could contain specially crafted content that could exploit the vulnerability. In all cases, however, an attacker would have no way to force users to view the attacker-controlled content. Instead, an attacker would have to convince users to take action, typically by getting them to click a link in an email message or in an Instant Messenger message that takes them to the attacker's website, or by getting them to open an attachment sent through email.

View more solutions

Comments

[Brad Christie]

Kind of makes sense. Looks like a (forced) migration and part of the vNext project where solutions rely on fewer dependencies coming from the framework.

[Abhishek]

Oh totally makes sense and a change for the better, but an unheralded out-of-band update that requires changes to existing code? Really bad form.

[Abhishek]

Soooo....that just basically says "it's a vulnerability where a user can be attacked via a webpage", right? Pretty useless description.

[xanadont]

It's worth noting that this also breaks existing projects that have Copy Local = True already set. At least for me, the project was no longer copying the assembly locally. Toggling to Copy Local = false, saving, then back to true and saving fixed it.

[Abhishek]

Holy cow that's awful. Everyone please go upvote that nuget bug.

[Abhishek]

This seems like some sort of confirmation

[realstrategos]

This can easily break your builds on your CI servers, confused the crap out of me the other day when my servers updated and were throwing this error but locally it was working (hadnt received the updates locally yet)

[Rob]

If anyone is confused in the future; it should be System.Web.Mvc, not System.Mvc.Web

[Danny Tuppeny]

Setting CopyLocal=true did not help us; see: System.Web.MVC not copied to bin folder since MS14-059

[Danny Tuppeny]

Setting CopyLocal=true did not help us; see: System.Web.MVC not copied to bin folder since MS14-059

[Abhishek]

@DannyTuppeny is the reference in the project file marked as <private>true</private> though?

[Abhishek]

This will only work if you have that version of mvc available locally or in the gac

[Danny Tuppeny]

@GeorgeMauer See my updates on that post; it is missing private=true, however upgrading to MVC 5.2.2 fixed it, and did not introduce any changes there :-/

[Hemslingo]

CopyLocal=True will put a local copy in the bin folder and run from that. Just make sure you upload it to the bin folder of the application on the test/production server.

[Abhishek]

Let me correct you there, <private>true</private> in your project file will be force it to be copied. Copy Local = True will sometimes force it to be copied because that entire feature is buggy. Unfortunately, as other people mentioned, an unrelated nuget bug will remove the <private>True</private> setting if you update from nuget and you will have to manually re-add it.

[Hemslingo]

I personally don't use nuget to reference the system namespace as this seems a bit convoluted, as you have just pointed out with the 'buggyness' you mentioned. but each to their own hey! This has worked for me and hopefully will shed some light on it for some other people.

[Abhishek]

What did that actually do to the csproj file? CopyLocal=true should just be a ui for making a change to the csproj file now.

[usefulBee]

Not sure what it did to the csproj file. Also CopyLocal was already set to true like other devs reported. However, all I know is after closing the solution or the Visual Studio instance and reopening it again, the error disappeared.

[Shawn Gavett]

Cleaning and rebuilding the Solution worked for me. Thank you for the suggestion

[3 rules]

Thanks it works but how it solved just don't get idea! Can you please give some little bit description how it solved?