MVC4 HTTP 错误403.14-禁止

the one i see more frequently recently is IIS and allowing 32bit applications to run

Is this what you have tried. otherwise we need more information about production and dev server versions

Error 403.14 is the HTTP error code for not being allowed to list the contents of a directory. Please be sure that

1. You have setup the website as an application in IIS
2. You have .NET 4.5 installed on the server
3. You have set the application pool to run the proper version of the .NET framework (ie. it is not set to .NET 2.0
4. You are using the integrated pipeline on your application pool
5. .NET 4.5 is actually registered in IIS. Please see this post for a similar issue/resolution

Usually, a and d are the biggest issues surrounding MVC deployments to IIS

Try

<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>

Via

https://serverfault.com/questions/405395/unable-to-get-anything-except-403-from-a-net-4-5-website

I have a bit different issue, on server 2012 somehow i forgot to enable asp.net 4.5 so if you have this issue, double check that you enable it.

There is a Refactor --> Rename Bug in Visual Studio 2012 that wrongly renamed the "id" inside the literal string value of the url parameter in my RouteConfig.cs. This caused a 403.14 on a fresh and otherwise correct setup in both Windows Server 2012 and Windows Server 2008 R2.

routes.MapRoute(
name: "Default",
url: "{controller}/{action}/{id}",
defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
);

was changed to

routes.MapRoute(
name: "Default",
url: "{controller}/{action}/{renamed_text}",
defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
);

Before applying

runAllManagedModulesForAllRequests="true"/>

consider the link below that suggests a less drastic alternative. In the post the author offers the following alteration to the local web.config:

  <system.webServer>
<modules>
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
</modules>

http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html

Perhaps... If you happen to use the Publish Wizard (like I did) and select the "Precompile during publishing" checkbox (like I did) and see the same symptoms...

Yeah, I beat myself over the head, but after unchecking this box, a seemingly unrelated setting, all the symptoms described go away after redeploying.

Hopefully this fixes some folks.

If you're running IIS 8.5 on Windows 8, or Server 2012, you might find that running mvc 4/5 (.net 4.5) doesn't work in a virtual directory. If you create a local host entry in the host file to point back to your local machine and then point a new local IIS website to that folder (with the matching host header entry) you'll find it works then.

I'm running Windows Server 2012 R2 on Azure and ASP.NET 4.5, IIS 8

I solved this problem by uninstalling all of the ASP.NET items in Programs and Features, then reinstalling ASP.NET like this with Server Manager using Add Roles and Features: picked Role-Based or Feature-Based installation, picked my server, and then for Select Server Role picked Web Server (IIS)/Web Server/Application Development, then clicked ASP.NET 4.5, confirmed installation of a prerequisite, and then reinstalled ASP.NET 4.5.

My previous searches had lead me to believe that the problem actually stems from a registration problem with ASP.NET. With earlier versions of ASP.NET, there is actually a utility that you can run to register ASP.NET without reinstalling, but that doesn't seem to be available any longer.

You can also get a 403 if when testing with dev server you are using integrated pipeline and then install as classic pipeline mode on your live IIS 7.5 web server, also I was missing my app_data folder which also was required

<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>

U can use above code

I had set the new app's application pool to the DefaultAppPool in IIS which obviously is using the Classic pipeline with .NET v.2.0.

To solve the problem I created a new App Pool using the Integrated pipeline and .NET v4.0. just for this new application and then everything started working as expected.

Don't forget to assign this new app pool to the application. Select the application in IIS, click Basic Settings and then pick the new app pool for the app.

I solve the problem opening the visual studio, expanding the references and changing the property "Copy Local" to "True".

I discover this comparing the dlls of the old version with the Dlls of my new version (that was not working)

In my case, my application's default page was index.html which was missing from the default document options. Adding it fixed the 403.14 Forbidden error.

In my case the issue was caused by custom ActionFilterAttribute which was a kind of global filter attribute. The attribute instantiated a service through Autofac but the service crashed in constructor:

public ActionFilterAttribute()
{
_service = ContainerManager.Resolve<IService>();
}


public class Service: IService
{
public Service()
{
throw new Exception('Oops!');
}
}

Windows-> Start -> Turn widows features on and off

Make sure you check required options in

In my case neither Windows Features nor aspnet_regiis -i didn't do the work. After hours of digging in the Internet, I made my own solution:

1. In the IIS Manager in Modules I changed inherit to local in UrlRoutingModule-4.0 node:

   

2. In web.config I pasted a mix of some tips from this forum:

   <system.webServer>
   <modules runAllManagedModulesForAllRequests="true">
   <remove name="UrlRoutingModule-4.0"></remove>
   <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition=""></add>
   </modules>
   </system.webServer>
   

Hope it helps

Either I inadvertently changed my application pool .NET CLR Version to: No Managed Code OR it was changed when I changed the application pool for my new .NET 5 web app that I deployed on the same server.

Changing my application pool .NET CLR Version back to: .NET CLR Version v4.0.30319 resolved the issue.