Cotten
Cotten

Reputation: 9077

ASP.NET Web API application gives 404 when deployed at IIS 7

I have an ASP.NET Web API which works fine when running on "IIS Express" with localhost:1783

Settings in VS

But when I uncross the "Use IIS Express" and then press "Create Virtual Directory"...

New settings

...I just get 404 errors: The 404 error

Any ideas whats wrong? Thanks!

Upvotes: 56

Views: 114523

Answers (12)

DavidAndroidDev
DavidAndroidDev

Reputation: 2414

All you really need to add to the web.config file is:

    <modules>
      <!-- Your other remove tags-->
      <remove name="UrlRoutingModule-4.0"/>
      <!-- Your other add tags-->
      <add name="UrlRoutingModule-4.0" path="*" verb="*" type="System.Web.Routing.UrlRoutingModule" preCondition=""/>
    </modules>

Note that none of those have a particular order, though you want your removes before your adds.

The reason that we end up getting a 404 is because the Url Routing Module only kicks in for the root of the website in IIS. By adding the module to this application's config, we're having the module to run under this application's path (your subdirectory path), and the routing module kicks in.

Upvotes: 42

user10760866
user10760866

Reputation: 41

I had this problem with Blazor and .Net Core and found that incorporating the NavManagers "baseUrl" into my calls to the controller solved the issue regardless of using a Virtual Directory or the root website.

This worked for me!

string baseUrl = NavigationManager.BaseUri.ToString();

NavigationManager.NavigateTo(**baseUrl** + $"api/Download/DownloadFile?FileName=" 
                                         + sFilename, true);

Upvotes: 1

Nida Akram
Nida Akram

Reputation: 362

Spend a whole week, after all the following setting worked ! and finally saved. Removing the UrlScan from ISAPI fileters in IIS fixes the problem in our case

Upvotes: 0

deadlydog
deadlydog

Reputation: 24434

For me I received a 404 error on my websites NOT using IIS Express (using Local IIS) while running an application that WAS using IIS Express. If I would close the browser that was used to run IIS Express, then the 404 would go away. For me I had my IIS Express project calling into Local IIS services, so I converted the IIS Express project to use Local IIS and then everything worked. It seems that you can't run both a non-IIS Express and Local IIS website at the same time for some reason.

Upvotes: 0

Moby&#39;s Stunt Double
Moby&#39;s Stunt Double

Reputation: 2550

For me, this issue was slightly different than other answers, as I was only receiving 404s on OPTIONS, yet I already had OPTIONS specifically stated in my Integrated Extensionless URL Handler options. Very confusing.

  1. As others have stated, runAllManagedModulesForAllRequests="true" in the modules node is an easy way to blanket-fix most Web API 404 issues - although I prefer @DavidAndroidDev 's answer which is much less intrusive. But there was something additional in my case.
  2. Unfortunately, I had this set in IIS under Request Filtering in the site:

OPTIONS Issue with Request Filtering

By adding the following security node to the web.config was necessary to knock that out - full system.webserver included for context:

  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true">
      <remove name="WebDAVModule" />
    </modules>
    <handlers>
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <remove name="OPTIONSVerbHandler" />
      <remove name="TRACEVerbHandler" />
      <remove name="WebDAV" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>
    <security>
      <requestFiltering>
        <verbs>
          <remove verb="OPTIONS" />
        </verbs>
      </requestFiltering>
    </security>
  </system.webServer>

Although it's not the perfect answer for this question, it is the first result for "IIS OPTIONS 404" on Google, so I hope this helps someone out; cost me an hour today.

Upvotes: 1

yannb
yannb

Reputation: 75

I have been battling this problem for a couple of days trying all kinds of things suggested. My dev machine was working fine, but the new machine I was deploying to was giving me the 404 error.

In IIS manager, I compared the handler mappings on both machines to realize that a lot of handlers were missing. Turns out that ASP.Net 5 was not installed on the machine.

Upvotes: 1

thebiggestlebowski
thebiggestlebowski

Reputation: 2789

For me, in addition to having runAllManagedModulesForAllRequests="true" I also had to edit the "path" attribute below. Previously my path attribute was "*." which means it only executed on url's containing a dot character. However, my application's url's don't contain a dot. When I switched path to "*" then it worked. Here's what I have now:

  <system.webServer>
      <validation validateIntegratedModeConfiguration="false" />
      <modules runAllManagedModulesForAllRequests="true">
      <remove name="WebDAVModule"/>
      </modules>

      <handlers>
          <remove name="WebDAV" />
          <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
          <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
          <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
          <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
          <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
          <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
      </handlers>
  </system.webServer>

Upvotes: 15

Sadish Kumar V
Sadish Kumar V

Reputation: 106

This issue can also happen due to the following

1.In the Web.Config

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

2.Make sure the following are available in the bin folder on the server where the Web API is deployed

•System.Net.Http

•System.Net.Http.Formatting

•System.Web.Http.WebHost

•System.Web.Http

These assemblies won't be copied in the bin folder by default if the publish is through Visual Studio because the Web API packages are installed through Nuget in the development machine. Still if you want to achieve these files to be available as part of Visual Studio publish then you need to set CopyLocal to True for these Assemblies

Upvotes: 8

SRIRAM
SRIRAM

Reputation: 19

I had as same problem . afer lot of R&D i found the problem.

but as long as your configuration are finne mean that aspnet 64 bit and the IIS well then the only problem i saw is the path " web api taking the local directiry path" so that you need to avid it. by like this.. ~../../../api/products/

thank you very much for posting the problem. i leanred alot abt iis and other setting in config file.

Upvotes: 0

Jeff
Jeff

Reputation: 31

Some people say runAllManagedModulesForAllRequests="true" will have performance issues and MVC routing issues. They suggest to use the following:

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

http://bartwullems.blogspot.com/2012/06/optimize-performance-of-your-web.html

Upvotes: 3

Tony
Tony

Reputation: 1937

You may need to install Hotfix KB980368.

This article describes a update that enables certain Internet Information Services (IIS) 7.0 or IIS 7.5 handlers to handle requests whose URLs do not end with a period. Specifically, these handlers are mapped to "." request paths. Currently, a handler that is mapped to a "." request path handles only requests whose URLs end with a period. For example, the handler handles only requests whose URLs resemble the following URL:

http://www.example.com/ExampleSite/ExampleFile.

After you apply this update, handlers that are mapped to a "*." request path can handle requests whose URLs end with a period and requests whose URLs do not end with a period. For example, the handler can now handle requests that resemble the following URLs:

http://www.example.com/ExampleSite/ExampleFile

http://www.example.com/ExampleSite/ExampleFile.

After this patch is applied, ASP.NET 4 applications can handle requests for extensionless URLs. Therefore, managed HttpModules that run prior to handler execution will run. In some cases, the HttpModules can return errors for extensionless URLs. For example, an HttpModule that was written to expect only .aspx requests may now return errors when it tries to access the HttpContext.Session property.

Upvotes: 11

mitaka
mitaka

Reputation: 2189

I you are using Visual Studio 2012, download and install Update 2 that Microsoft released recently (as of 4/2013).

Visual Studio 2012 Update 2

There are some bug fixes in that update related to the issue.

Upvotes: 0

Related Questions