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>
I had the same issue: on a newly installed machine with Visual Studio 2013, the web api project was working under IISExpress, but not under local IIS. I tried everything I could find, but in the end the problem was not necessary with Web API, but with MVC: even it was installed, no MVC project was running.
What worked for me was to uninstall IIS (from ADD/REMOVE Windows Features), then reinstall it, and then run aspnet_regiis -i. Maybe this helps somebody else.
This is the only answer that worked for me...
I had a similar issue... It seemed like no matter what I did, nothing was getting redirected and my global file was just being ignored. I seriously considered just ending it all before I found this answer. I hope this link helps somebody else.
Adding the following to the web.config file worked for me:
system.webServer tag was already there of course but I added the modules tag to it and then the remove & add tags to modules tag.
I started getting 404 responses from Web API after following a Windows Azure tutorial that told me to add a file "WebRole.cs" to my project.
After removing "WebRole.cs" from my project, my Web API calls started working again.
Ensure that not selected Solution -> Project -> Right click Properties -> Application -> Auto-generate binding redirects
Are you running the Web API app in a virtual directory or an application?
For example: I had the same issue when I moved my project to my local IIS under the Default Web Site > SampleWebAPI. I believe this is due to the change in the
URL
routing as follows:Original:
localhost:3092/api/values
Moved:
localhost/SampleWebAPI/api/values
If you move the Web API project to it's own website running on a different port it seems to work.
Additional note: I had further complicated the issue by adding
api
as the alias of an application within my website which caused the effectiveURL
to be:localhost:81/api/api/values
- noticed this after moving the website to it's own websiteTherefore, because I wanted to maintain a separation between my website and the web api mvc project site, I changed the routing rules in
global.asax
for the Web API "DefaultAPI" fromapi/{controller}/{id}
to{controller}/{id}
and the ASP.NET MVC oneDefault
from{controller}/{id}
toinfo/{controller}/{id}
.Ran into the same issue with Web API and .Net Core Web API. Worked fine in VS 2017 while debugging, but returned 404 when published to IIS 7.5. Solution for me was to change the way I created the site. Instead of publishing to the root of a Web Site (created by right clicking Sites...Add Web Site), I had to create an Application (created by right clicking a Web Site...Add Application) and publish to that folder. Note that for the Core version, I had to change the Application Pool .NET Framework Version setting to "No Managed Code".