We Keep Coding

404 error after deploying to IIS

Before deploying my ASP.net software to the production site (Windows server 2012 R2), I first test the software on a test server. If that is succesful, I deploy (copy) the exact same software to the production site.
On the production site, I got the following error when clicking on a link:
Warning, an 404 error has been detected: System.Web.HttpException (0x80004005): The file '/Account/Login.aspx' does not exist.
at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal...
Note that the path '/Account/Login.aspx' was a part of the previous version of the deployed software. The path no longer exists in the current version.
I have tried to make a "clean-ip" by deleting the content in:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root
but that did not help.
How do I find the root cause for the 404 error?
How do I prevent old stuff from previous versions of the deployed software from making trouble in the latest deployed version?

Thank you for trying to help me by adding comments to my question.
I have found that adding the following lines to 'web.config' file removes the error. I dont know why but the main thing is that it now works:
<appSettings>
....
<add key="ValidationSettings:UnobtrusiveValidationMode" value="None"/>
<add key="UserLockoutEnabledByDefault" value="true"/>
<add key="DefaultAccountLockoutTimeSpan" value="10"/>
<add key="MaxFailedAccessAttemptsBeforeLockout" value="3"/>

ASP.NET BlogEngine.NET HTTP 403 Error (Admin Pages Only)

I recently installed the latest version of BlogEngine.NET (v3.0). The blog itself renders fine on my browser (i.e., viewing the main page, individual blog posts, etc.) However, when I log in and try to access any of the Admin pages (i.e., Settings, Users, etc.), I am getting an HTTP 403 (Forbidden) error.
This is happening on both Windows Server 2008 R2 x64 as well as Windows Server 2012 x64. When I installed a local copy on my Windows 8.1 Pro machine, it works fine.
I know the admin pages all render in MVC-style, since the URL is "/admin/#/settings", for Settings for example.
I have literally tried everything. I verified that the application pool identity has Write permissions to the entire web site folder structure.
Any thoughts/ideas? I am completely stuck and would appreciate any guidance. Thanks in advance.
* UPDATE *
Some progress- I tried creating a standalone website in IIS just for BlogEngine.NET, i.e., http://www.example.com instead of http://www.example.com/blog, and it worked flawlessly.
Therefore, something is going screwy with the permissions when I am creating an Application within the main Website (i.e., www.example.com/blog).
Thoughts?

Ancient post, but adding these <appSettings> helped for me:
<appSettings>
<add key="webpages:Version" value="3.0.0.0" />
<add key="webpages:Enabled" value="true" />
</appSettings>
Alternatively, you can start the section by getting rid of all inherited values:
<appSettings>
<clear />
<!-- Other settings here -->
</appSettings>
In my main site I explicitly had a setting <add key="webpages:Enabled" value="false" />, so that explains why it was necessary to add this.
You also need to do this for other sections, like <connectionStrings>.

C# and Razor - The type of page you have requested is not served because it has been explicitly forbidden. The extension '.cshtml' may be incorrect

I have looked through other posts but none seem to answer what I need.
I created an empty site in WebMatrix (ASP.NET)
I opened that site in VWD 2013
I hit F5 and it runs fine on a URL such as http://local.com:59833/ContentPage.cshtml
I go to http://local.com/cscsu_bi/ContentPage.cshtml and it doesn't work with the error below
Server Error in '/' Application.
This type of page is not served.
Description: The type of page you have requested is not served because it has been explicitly forbidden. The extension '.cshtml' may be incorrect. Please review the URL below and make sure that it is spelled correctly.
Requested URL: /cscsu_bi/ContentPage.cshtml
The web.config file is as follows
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="webpages:Enabled" value="true" />
</appSettings>
<system.web>
<compilation debug="true" targetFramework="4.0" />
</system.web>
</configuration>
I am on Windows 7. Is there anything obvious I'm doing wrong?
Thanks

I was missing the Microsoft.AspNet.WebPages NuGet package. Installing it solved my problem. (This package has dependencies on Microsoft.Web.Infrastructure and Microsoft.Web.Razor and thus includes them for you)
If you use the NuGet console, just type:
Install-Package Microsoft.AspNet.WebPages

I have set up Razor on a number of machines, and often find that I need to include the following DLLs in my bin folder:
System.Web.Razor.dll
System.Web.WebPages.Deployment.dll
System.Web.WebPages.dll
System.Web.WebPages.Razor.dll
Microsoft.Web.Infrastructure.dll

Take a look at this article.
http://www.asp.net/web-pages/overview/more-resources/aspnet-web-pages-(razor)-troubleshooting-guide
This fixed my issue after reviewing all IIS settings and references.
Make sure that the root of your website has at least one .cshtml file in it.

This may not be your exact issue, but I have had this happen for a couple reasons:
Incorrect Framework on Server: Make sure the target framework of the
project is supported by the server. Just changing the
targetFramework attribute of the compilation element may not be
enough as the DLLs for your project may be compiled
against the 4.5 framework.
Incorrect Framework of Application Pool: This can also happen if
your application pool is not using the right .Net CLR version. Make
sure it is using the 4.0 instead of 2.0

In my case the culprit was the fact that Global.asax was placed under the '/Views' folder. This was somehow working while the project was targeting MVC3. Once the solution got upgraded to MVC4, running said solution would result in the aforementioned errors. In a similar vein, other errors would crop up mentioning:
"no default webpage has been set and directory browsing has been disabled"
The solution: After upgrading to MVC4+ I had to manually move Global.asax under the root folder of the container project. Be sure to inspect Global.asax to make sure that the namespace applied within is the proper one. Just my 2c.

In my case I set webpages:Enabled to true under appSettings:
<appSettings>
<add key="webpages:Enabled" value="false" />
</appSettings>
According to post: what is the function of webpages:Enabled in MVC 3 web.config, this prevents files in the Views folder from being directly accessible from a web browser.

How to get IIS to recognize OWIN startup class?

My OWIN web service runs beautifully in Visual Studio 2013, but when I publish it to a real IIS site, it acts as if the Configuration method in the startup class has not been run. I can do "normal" things like browse to the app and see the directory structure, but nothing that was supposedly set up with the IAppBuilder is functional. For example, I get a 404.0 error when I browse to a URL that was set up in Startup to issue an OAuth2 bearer token. It's as if Startup.Configuration(IAppBuilder app) was never run.
I'm using the [assembly: OwinStartup(typeof(MyNamespacedStartupClass))] attribute to designate the startup class.
I've used NuGet to get both Microsoft.Owin.Host.SystemWeb and Microsoft.Owin.Diagnostics per instructions I've seen, but that doesn't make a difference.
What more do I have to do?

Make sure your app pool is in v4.0 integrated mode.
Make sure you have bin placed Microsoft.Owin.Host.SystemWeb (I see you have installed it) - Just make sure its also in the bin folder.
This article will have more information on how an OWIN middleware runs on Integrated pipeline.

I also had to add an extra setting to my web.config
<configuration>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
</configuration>
From: https://katanaproject.codeplex.com/wikipage?title=Static%20Files%20on%20IIS
IIS has a native static file module that is optimize to skip other
portions of the pipeline if it sees file paths that do not match other
handlers (e.g. not aspx). This means that the directory browser
middleware is likely to work, but then the static file middleware may
be bypassed in favor of the native static file module.
This tells IIS not to skip the managed Asp.Net modules even if the
native static file module thinks it has a match.
It also describes another step, but this was not needed for me:
Also, add the following stage marker AFTER your static file middleware
(in namespace Microsoft.Owin.Extensions):
app.UseStageMarker(PipelineStage.MapHandler);

Probably the reason if you upgraded at some point from an older MVC:
Make sure you don't have
<add key="owin:AutomaticAppStartup" value="false" />
in your web.config. It will suppress calling the startup
Instead change it to this
<add key="owin:AutomaticAppStartup" value="true" />
Somewhere along the line - when I upgraded to MVC 5 this got added (actually almost ironically it was a year ago tomorrow) and I never even knew what owin was until today when I tried to use it.

I also faced same problems when I migrated my already running MVC5 site to a new server. It gave me nightmares, just to recap I had to do all this to get it working
Add [assembly: OwinStartupAttribute(typeof([YourAssemblyName].Startup))] this to the Startup class (after the using statements and before the namespace declaration)
Add these keys to the <appSettings> section of web.config
<add key="owin:AppStartup" value="[NamespaceForYourStartUpClass].Startup, [YourAssemblyName]" />
<add key="owin:AutomaticAppStartup" value="true" />
And lastly as suggested by Martijn Evens add the following to <system.webserver> section in web.config
<modules runAllManagedModulesForAllRequests="true" />

For those who deal with legacy and (or) have migrated versions. Check windows "Roles and features", find what version of ASP.net is installed, and use exactly the same version in web.config for targetFramework, for example in my case it was 4.6 not 4.8, so
<system.web>
<httpRuntime targetFramework="4.6" requestValidationMode="2.0" maxQueryStringLength="2097151" />
<compilation targetFramework="4.6" optimizeCompilations="true">

Getting "The WebResource.axd handler must be registered in the configuration to process this request." error

I'm getting this error while running my ASP.NET app on IIS7. I've tried doing what it says to do but it doesn't help.
The WebResource.axd handler must be
registered in the configuration to
process this request.
> <!-- Web.Config Configuration File -->
>
> <configuration>
> <system.web>
> <httpHandlers>
> <add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="True" />
> </httpHandlers>
> </system.web>
> </configuration>
I'm using a little bit of AJAX which is what I think is causing the issue. Has anyone encountered this before?

I figured it out so I'm posting it here for search reasons. It is a bug in ASP.NET and it has to do with having ColdFusion installed. Microsoft hasn't yet released a fix.
There are two ways to fix this.
Change the AppPool in IIS7 to "Classic .NET AppPool". I'm not sure of any implications with this setting.
Remove all the references to ColdFusion from your applicationHost.config file in system32\inetsrv\config.

ColdFusion installs a global wildcard handler mapping which apparently overrides many of the standard .NET handlers. The solutions mentioned work just fine, but if you can't switch to Classic Mode and don't want to screw with your ColdFusion installation, you can remove the inherited handler mapping at the individual site level.
To do this, go to the site in question in IIS, double-click on "Handler Mappings" under the "IIS" section, and find the handler named something like "AboMapperCustom-XXXXXX" with "*" for the Path. Select the entry and click "Remove" in the sidebar. This will only remove the mapping for your application, so it won't break any existing CF sites on the server.

In IIS7 you need to add the <httpHandler> section to <system.webServer> instead of <system.web>. Here is an example.

I got this error after carelessly copying my app's web.config between a pair of clustered servers, which overwrote the tag:
<system.webServer>
<handlers>
<remove name="AboMapperCustom-XXXXXXXX" />
</handlers>
</system.webServer>
with
<system.webServer>
<handlers>
<remove name="AboMapperCustom-YYYYYYYY" />
</handlers>
</system.webServer>
Locating the proper ID as per Josh's response and correcting the tag fixed it, but more importantly, will presumably keep that handler mapping from sneaking back in.

The issue happened to me on new Windows 2016 server where ASP.NET 4.6 was not installed. After installation everything got fixed.
Steps
- Run Server Manager
- Manage > Add Roles and Features
- Server Roles
- Web Server (IIS) > Web Server > Application Development > ASP.NET 4.6

I had this problem and that reason was incompatibility between Coldfusion and some configurations of ASP.NET applications when IIS App pool is in integrated mode. Coldfusion must be disable .