HTTP 404 Page Not Found in Web Api hosted in IIS 7

Question

I have a Web Api application. It works perfectly well when I tested it using the VS 2010 debugging dev server. But I now deployed it to IIS 7.5 and I am getting a HTTP 404 error when trying to access the application.

Here is my web.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <connectionStrings>
    <add name="DefaultConnection" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=aspnet-FlowGearProxy-20123141219;Integrated Security=True" providerName="System.Data.SqlClient" />
  </connectionStrings>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="true" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  </appSettings>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login" timeout="2880" />
    </authentication>
    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="true" />
  </system.webServer>
</configuration>

Answer 1

There is official fix from microsoft: http://support.microsoft.com/kb/980368

I strongly do NOT recommend to use < modules runAllManagedModulesForAllRequests="true">. This leads all requests (even .jpg, .css, .pdf, etc) will be processed by all registered HTTP modules. There are two negative moments: a) additional load on hardware resources; b) potential errors, as http modules will process new type of content.

Answer 2

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

Sadish Kumar.V

Answer 3

I struggled with this, as well. My exact issue was that I had an ASMX Web Service that, when I entered a parameter into a web method and tested it, then it would give me the 404. The particular method had worked fine in the past and hadn't been changed, only re-published. Then I got here and tried all of the posted answers & nothing helped.

My ultimate solution? I know this is drastic, but I just created a new Visual Studio solution and web project. Selected MVC, then I did an "Add" > "New Item", selected "Visual C#" > "Web" and "Web Service (ASMX)" under that. I copied all of my old code-behind code, then I took note of the namespace it gave the new file in my new project, then pasted all of my old code into the new code-behind file in the new project and put the namespace back to what it had been.

Then I created my folders in my project that I had before using Visual Studio to do "Add" > "New Folder", then copied back in my files into the folders from my other project using Windows Explorer, then right-clicked each folder in Visual Studio and did "Add" > "Existing Item..." and pulled the items in those folders into my new project's Visual Studio folders. I referenced all my .NET assemblies again, having both projects open so I could compare which ones I had referenced, previously (there were several). I had to name my new project slightly different - basically I did something comparable to "GeneralWebApp" instead of "MyWebApp", for example - so I had to do a "Replace All" in my whole solution to replace that name, so it would get the right namespace for all my files.

Then I did a "Rebuild All" on the project, then started it up with the "Play" button Visual Studio gives when I got it to build correctly. It worked fine. So I published it, and everything was fine on the server where I published it, when I ran it from there. I have no explanation as to what happened, but that's how I got through it. It's not a bad test just to see if something Visual Studio is doing has mucked it up.

Answer 4

Try this webconfg.. replace "NewsApi.dll" with your main dll!

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet" arguments=".\NewsApi.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
    </system.webServer>
  </location>
</configuration>

Answer 5

I had to disable the File Publish Option "Precompile during publishing."

Answer 6

I was struggling with this as well. Fortunately, Steve Michelotti documented a solution that worked for me here.

At the end of the day, I enabled all verbs (verb="*") to the ExtensionlessUrlHandler-Integrated-4.0 handler in my web config.

<system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="true" />
        <handlers>
            <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
            <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" />
        </handlers>
</system.webServer>

Others have pointed out that having WebDAV enabled causes issues. Fortunately, I did not run into that issue as well.