“Missing web components” error when opening MVC3 p

问题:

When I open a solution containing an MVC3 project in Visual Studio 11 Beta, I see the following message:

The Web project 'Landboss.Web' requires missing web components to run with Visual Studio. Would you like to download and install them using the Web Platform Installer now? (Note: Some components might require restart to take effect.)

ASP.NET Web pages with Razor syntax 1.0.0.0

When I click Yes, the Web Platform Installer opens and tells me this:

The product you are trying to install is not supported on your operating system. Click here for more information.

So far I've installed Visual Studio 11 Beta on two machines and both have this same problem.

回答1:

I believe this was caused by the fact that I had previously installed Visual Studio 11 Developer Preview. I did uninstall it before installing the Beta, but you know how that goes.

To fix it, I did the following:

1. Uninstalled "Microsoft ASP.NET MVC 3 - Visual Studio 11 Tools Update"
2. Uninstalled "Microsoft ASP.NET Web Pages - Visual Studio 11 Tools"
3. Ran the Visual Studio 11 Beta "Repair" from the installation ISO.

It worked! Razor syntax highlighting and intellisense are back, and the warning message no longer shows when I open the project.

回答2:

This is related to the configuration setting webpages:Version

[appSettings]
...
   [add key="webpages:Version" value="x.0.0.0" /]
...
[/appSettings]

if you have multiple versions of razor on the system (1 or 2 for now), better add this setting if it's missing. Choose the version you want/need at the appropriate level. (Obviously replace the brackets...)

回答3:

I have also had this error happen when a Subversion conflict was committed to the repository - the presence of this block in the web.config's app settings seemed to trigger the message when loading the project:

<<<<<<< .mine
<add key="blogCommentsApprovedByDefault" value="false" />
(other appsettings)
=======
<add key="blogCommentsApprovedByDefault" value="false" />
(other appsettings)
>>>>>>> .r358

Cleaning up the Subversion conflict in appSettings resolved this error.

回答4:

While @silent__thought's solution may correct the problem, it's not the easiest way to fix it.

@Costas solution may exactly address the problem, but here is a more detailed explanation if you need it.

In my case, I needed the following in my web.config file (for MVC 4):

<configuration>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="false" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  </appSettings>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
    <httpHandlers></httpHandlers>
  </system.web>
</configuration>

Of course, you may not need all of these configurations for your app. These just happen to be the default settings for an MVC 4 project.

回答5:

I got this error because the appSettings section was setup to be encruypted, and the encryption keys were not setup correctly. It seems this error has a tendancy to popup whenever there is something wrong/malformed with web.config even if unrelated to MVC.

回答6:

I got this error when something in the web.config file was corrupted. I simply formatted the file and then resaved it. Then I restarted Visual Studio.

回答7:

I've just been bitten by this and it's another variation of the web.config problem. In my case we do not store a web.config file in our repo but generate one from a template as a custom build step. When we do a clean of the workspace* this file was being deleted (rightly so because it's not in the repo) and so the next time Visual Studio was started it complained. A command line build via msbuild was never affected by this.

*We have a "partial" clean, which deletes all the build artefacts (including those VS leaves behind) and a "full" clean that resets the workspace to the same state as if you had just pulled it from the repo.