[.net] MVC4 HTTP Error 403.14 - Forbidden

I have build a .net4.5 ASP.NET MVC4 web app which works fine locally (IIS Express & dev server) but once i deploy it to my web server it throws the 403 error. I have installed .Net 4.5RC on the server and even tried the aspnet_regiis -i bit that everyone recommended for their issues with previous versions of MVC/.Net but it did not help.

Any ideas?

EDIT: More info about the situation. The server is 32bit and I have 4 other MVC3 applications that work fine. It is just my MVC4 app that is not working.

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

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

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.

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 }
);

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

U can use above code

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

Make sure you check required options in

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

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

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!');
    }
}

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.

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.

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.

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

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.

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 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)