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.
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
Error 403.14 is the HTTP error code for not being allowed to list the contents of a directory. Please be sure that
You have setup the website as an application in IIS You have .NET 4.5 installed on the server You have set the application pool to run the proper version of the .NET framework (ie. it is not set to .NET 2.0 You are using the integrated pipeline on your application pool .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
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.
Windows-> Start -> Turn widows features on and off
Make sure you check required options in
https://i.stack.imgur.com/n3v1N.png
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
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 }
);
null
for the name
parameter to avoid making up a name for every route. It turns out that this also causes a 403 sometimes (only on our prod environment, Win Server 2008 R2 running .NET 4.5.1, MVC 5 in a VS2013 project. To resolve I added a name for each route.
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
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.
<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.
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
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'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.
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!');
}
}
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:
In the IIS Manager in Modules I changed inherit to local in UrlRoutingModule-4.0 node: In web.config I pasted a mix of some tips from this forum:
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.
Success story sharing