Page HTTP 404 introuvable dans l'API Web hébergée dans IIS 7.5

J'ai une application Web Api. Cela fonctionne parfaitement bien lorsque je l'ai testé en utilisant le serveur de développement de débogage VS 2010. Mais je l'ai maintenant déployé sur IIS 7.5 et j'obtiens une erreur HTTP 404 en essayant d'accéder à l'application.

Voici mon 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>

J'avais aussi du mal avec ça. Heureusement, Steve Michelotti a documenté une solution qui a fonctionné pour moi ici .

À la fin de la journée, j'ai activé tous les verbes (verb = "*") pour le gestionnaire ExtensionlessUrlHandler-Integrated-4.0 dans ma configuration Web.

<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>

D'autres ont souligné que l'activation de WebDAV pose des problèmes. Heureusement, je n'ai pas non plus rencontré ce problème.

Eu le même problème. Ce paramètre de configuration a résolu le problème.

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

Comme expliqué dans http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html, la solution ci-dessus doit être évitée. Utilisez plutôt ceci. La même solution est également fournie par Lopsided. Gardez-le ici pour permettre aux utilisateurs d'éviter d'implémenter la première solution de travail.

<modules>
  <remove name="UrlRoutingModule-4.0" />
  <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
  <!-- any other modules you want to run in MVC e.g. FormsAuthentication, Roles etc. -->
</modules>

Si IIS est installé ou activé après ASP.NET, vous devrez enregistrer manuellement ASP.NET auprès d'IIS pour que votre application .NET fonctionne.

Pour Windows 7 et versions antérieures:

1. Exécutez l'invite de commandes (cmd.exe) en tant qu'administrateur.
2. Accédez à l'emplacement .NET Framework approprié. (par exemple C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319)
3. Exécutez aspnet_regiis.exe -i

Pour Windows 8 et versions ultérieures:

1. Dans le menu Démarrer, tapez "Activer ou désactiver les fonctionnalités de Windows" et sélectionnez le premier résultat.
2. Développez Internet Information Services: World Wide Web Services: Fonctionnalités de développement d'applications et sélectionnez ASP.NET 4.5 (ou ASP.NET 3.5 si vous devez prendre en charge des projets sur .NET Framework 2.0-3.5).
3. Cliquez sur OK.

Exécutez-vous l'application API Web dans un répertoire virtuel ou une application?

Par exemple: j'ai eu le même problème lorsque j'ai déplacé mon projet vers mon IIS local sous le site Web par défaut> SampleWebAPI. Je pense que cela est dû au changement de URLroutage comme suit:

Original: localhost:3092/api/values
déplacé: localhost/SampleWebAPI/api/values

Si vous déplacez le projet d'API Web vers son propre site Web fonctionnant sur un port différent, cela semble fonctionner.

Note supplémentaire: j'avais encore compliqué le problème en ajoutant apicomme alias d'une application sur mon site Web, ce qui a fait en sorte que l'efficacité URLsoit:

localhost:81/api/api/values - remarqué cela après avoir déplacé le site Web vers son propre site Web

Par conséquent, parce que je voulais maintenir une séparation entre mon site Web et le site de projet mvc global.asaxde l'API Web , j'ai changé les règles de routage pour l'API Web "DefaultAPI" de api/{controller}/{id}à {controller}/{id}et ASP.NET MVC Defaultde {controller}/{id}à info/{controller}/{id}.

C'est la seule réponse qui a fonctionné pour moi ...

J'ai eu un problème similaire ... Il semblait que peu importe ce que je faisais, rien n'était redirigé et mon fichier global était simplement ignoré. J'ai sérieusement envisagé de mettre fin à tout cela avant de trouver cette réponse. J'espère que ce lien aide quelqu'un d'autre.

• Débordement de pile - Diagnostic des erreurs 404 sur IIS 7 et ASP.NET MVC

L'ajout de ce qui suit au fichier web.config a fonctionné pour moi:

<system.webServer>
  <modules>
    <remove name="UrlRoutingModule-4.0" />
    <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
  </modules>
</system.webServer>

La balise system.webServer était déjà là bien sûr, mais j'y ai ajouté la balise modules , puis la balise remove & add to modules.

Quelques points à vérifier:

1. Assurez-vous que .NET Framework 4 est installé.
2. Assurez-vous que la version 4 du .NET Framework est sélectionnée pour votre site Web et votre répertoire virtuel (le cas échéant).
3. Assurez-vous que MVC est installé ou que les DLL appropriées sont dans votre répertoire bin.
4. Il peut être nécessaire d'autoriser les extensions de service Web ASP.NET 4.0
5. Placez l'application dans son propre pool d'applications.
6. Assurez-vous que le répertoire dispose au moins des autorisations d'exécution "Scripts seulement".

J'avais un problème similaire. J'avais les bons paramètres dans mon fichier web.config mais j'exécutais le pool d'applications en mode classique plutôt qu'en mode intégré

Ce problème peut également survenir pour les raisons suivantes

1.Dans le Web.Config

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

Assurez-vous que les éléments suivants sont disponibles dans le dossier bin sur le serveur sur lequel l'API Web est déployée

• System.Net.Http

• System.Net.Http.Formatting

• System.Web.Http.WebHost

• System.Web.Http

Ces assemblys ne seront pas copiés dans le dossier bin par défaut si la publication s'effectue via Visual Studio, car les packages d'API Web sont installés via Nuget sur l'ordinateur de développement. Si vous souhaitez que ces fichiers soient disponibles dans le cadre de la publication de Visual Studio, vous devez définir CopyLocal sur True pour ces assemblys.

Sadish Kumar.V

Sur la base de cette réponse SO , je viens d' avoir à changer path="*."à path="*"la ajoutée ExtensionlessUrlHandler-Integrated-4.0dansconfiguration>system.WebServer>handlers monweb.config

Avant:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

Après:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

J'ai également rencontré ce problème. J'ai résolu le problème en accédant aux pools d'applications> Nom du pool d'applications et j'ai changé le .NET Framework de la version v.2.0.50727 à v4.0.30319.

J'ai dû désactiver l'option de publication de fichier «Précompiler lors de la publication».

Il existe un correctif officiel de Microsoft: http://support.microsoft.com/kb/980368

Je ne recommande fortement PAS d'utiliser <modules runAllManagedModulesForAllRequests = "true">. Cela conduit toutes les demandes (même .jpg, .css, .pdf, etc.) seront traitées par tous les modules HTTP enregistrés. Il y a deux moments négatifs: a) charge supplémentaire sur les ressources matérielles; b) des erreurs potentielles, car les modules http traiteront un nouveau type de contenu.

J'ai commencé à recevoir 404 réponses de l'API Web après avoir suivi un didacticiel Windows Azure qui m'a dit d'ajouter un fichier «WebRole.cs» à mon projet.

Après avoir supprimé "WebRole.cs" de mon projet, mes appels d'API Web ont recommencé à fonctionner.

Assurez-vous que le pool d'applications est en mode intégré
et ajoutez ce qui suit au fichier web.config:

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

Dans mon cas, le problème était simplement que j'essayais d'accéder au site à l'adresse

myserver.myintranet.com/mysite

Mais la liaison de site Web pour http dans IIS n'avait pas le nom d'hôte spécifié dans la liaison. Cela avait fonctionné avant et je ne sais pas comment cela a été époustouflé.

Une fois que j'ai mis myserver.myintranet.comle nom d'hôte, le 404 était parti.

Dans IIS Manager, vous accédez aux liaisons ... dans le volet Actions, puis modifiez la liaison http pour spécifier le nom d'hôte.

N'oubliez pas de déployer global.asax

Eu le même problème, une réponse 404 pour les contrôleurs de l'API Web lorsqu'ils sont servis depuis l'IIS, mais tout a bien fonctionné à partir de VS2010. Aucune des solutions ci-dessus n'a fonctionné pour moi. Finalement, j'ai trouvé que le problème était que nous avons ajouté la prise en charge de WSE 3.0 pour l'application et que la DLL Microsoft.Web.Services3 était manquante dans le répertoire / bin de l'application. Bizarre, mais après avoir copié la dll, le mappage d'itinéraire a commencé à fonctionner.

Pour moi, le problème était que le site racine était configuré pour utiliser un pool d'applications .NET 2.0, et mon application dans ce site était .NET 4.5.

J'ai créé un nouveau site avec un pool d'applications .NET 4 et placé mon application à la racine de celui-ci - et cela a bien fonctionné.

J'ai aussi eu du mal avec ça. Mon problème précis était que j'avais un service Web ASMX qui, lorsque je saisissais un paramètre dans une méthode Web et que je le testais, me donnait le 404. La méthode particulière avait bien fonctionné dans le passé et n'avait pas été modifiée, seulement republié. Ensuite, je suis arrivé ici et j'ai essayé toutes les réponses publiées et rien n'a aidé.

Ma solution ultime? Je sais que c'est drastique, mais je viens de créer une nouvelle solution Visual Studio et un nouveau projet Web. MVC sélectionné, puis j'ai fait un "Ajouter"> "Nouvel élément", sélectionné "Visual C #"> "Web" et "Service Web (ASMX)" en dessous. J'ai copié tout mon ancien code code-behind, puis j'ai pris note de l'espace de noms qu'il a donné au nouveau fichier dans mon nouveau projet, puis j'ai collé tout mon ancien code dans le nouveau fichier code-behind du nouveau projet et mis l'espace de noms retour à ce qu'il avait été.

Ensuite, j'ai créé mes dossiers dans mon projet que j'avais avant d'utiliser Visual Studio pour faire "Ajouter"> "Nouveau dossier", puis j'ai recopié mes fichiers dans les dossiers de mon autre projet à l'aide de l'Explorateur Windows, puis j'ai fait un clic droit sur chaque dossier dans Visual Studio et fait "Ajouter"> "Élément existant ..." et extrait les éléments de ces dossiers dans les dossiers Visual Studio de mon nouveau projet. J'ai de nouveau référencé tous mes assemblys .NET, en ouvrant les deux projets afin de pouvoir comparer ceux que j'avais référencés auparavant (il y en avait plusieurs). J'ai dû nommer mon nouveau projet légèrement différent - en gros, j'ai fait quelque chose de comparable à "GeneralWebApp" au lieu de "MyWebApp", par exemple - donc j'ai dû faire un "Replace All" dans toute ma solution pour remplacer ce nom,

Ensuite, j'ai fait un "Rebuild All" sur le projet, puis je l'ai démarré avec le bouton "Play" que Visual Studio donne quand je l'ai construit correctement. Cela a bien fonctionné. Alors je l'ai publié, et tout allait bien sur le serveur où je l'ai publié, quand je l'ai lancé à partir de là. Je n'ai aucune explication sur ce qui s'est passé, mais c'est ainsi que je m'en suis sorti. Ce n'est pas un mauvais test juste pour voir si quelque chose que Visual Studio fait a tout gâché.

Si vous placez uniquement le dossier bin dans IIS (après la création du projet), ce problème se produira également. Dans cette situation, vous devez publier le projet à l'aide de VisualStudio, puis placer le dossier publié dans IIS.

Quel type de requête HTTP faites-vous?

Ceci est une réponse légèrement à gauche, mais avez-vous essayé de supprimer la page d'erreur par défaut IIS pour 404 pour vérifier ce que votre API renvoie réellement?

J'ai eu un problème dans lequel je voulais une méthode de contrôleur pour renvoyer un 404 lorsque je POSTÉ le mauvais identifiant. J'ai constaté que j'obtenais toujours la page IIS 404 «Fichier ou répertoire non trouvé» plutôt que la réponse HTTP de mon API. La suppression de la page d'erreur 404 par défaut a résolu le problème.

Problème différent mais vous ne savez jamais que cela peut aider;)

Ce morceau de configuration dans le fichier web.config peut m'aider comme aidé: dans la section system.webServer:

      <security>
          <requestFiltering>
              <verbs applyToWebDAV="true">
                  <remove verb="PUT" />
                  <add verb="PUT" allowed="true" />
                  <remove verb="DELETE" />
                  <add verb="DELETE" allowed="true" />
                  <remove verb="PATCH" />
                  <add verb="PATCH" allowed="true" />
              </verbs>
          </requestFiltering>
      </security>      

J'ai récemment eu une erreur 404 non trouvée avec toutes mes routes / contrôleurs Web Api 2. Je suis donc allé sur le serveur réel et j'ai essayé de naviguer en utilisant localhost au lieu du nom d'hôte et j'ai obtenu "404.7 Not Found - Le module de filtrage des demandes est configuré pour refuser l'extension de fichier".

Ce message SO m'aide à le résoudre.

Cela a été résolu pour moi, lorsque j'active la case à cocher pour UrlRoutingModule-4.0:

IIS Manager> Modules> sélectionnez UrlRoutingModule-4.0> Edit Module> cochez la case "Invoke only for requests to ASP.NET applications or managed handlers".

J'ai eu le même problème: sur une machine nouvellement installée avec Visual Studio 2013, le projet d'API Web fonctionnait sous IISExpress, mais pas sous IIS local. J'ai essayé tout ce que j'ai pu trouver, mais au final le problème n'était pas nécessaire avec l'API Web, mais avec MVC: même s'il était installé, aucun projet MVC n'était en cours d'exécution.

Ce qui a fonctionné pour moi était de désinstaller IIS (à partir des fonctionnalités ADD / REMOVE Windows), puis de le réinstaller, puis d'exécuter aspnet_regiis -i. Peut-être que cela aide quelqu'un d'autre.

J'ai passé beaucoup de temps à essayer beaucoup de choses pour finalement réaliser que j'ajoutais mon application Web non pas dans Sites / Sites Web par défaut, mais dans un autre site Web lié à un autre port. Évidemment, essayer localhost sur le port 80 donnerait un 404.

je ne fais rien, ajoutez simplement cette balise dans web.config, son fonctionnement ce problème soulève l'un des points suivants

1. Utiliser Web Api dans le même projet à l'aide de formulaires MVC ou asp.net

2. Utilisez RouteConfig et WebApiConfig dans Global.asax comme GlobalConfiguration.Configure (WebApiConfig.Register); RouteConfig.RegisterRoutes (RouteTable.Routes);

3. Utilisez RouteConfig à deux fins, les formulaires asp.net en utilisant le routage friendlyurl et mvc pour le routage MVC

nous utilisons simplement cette balise dans web.config, cela fonctionnera.

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

Ran dans le même problème avec l'API Web et l'API Web .Net Core. A bien fonctionné dans VS 2017 lors du débogage, mais a renvoyé 404 lors de la publication dans IIS 7.5. La solution pour moi était de changer la façon dont j'ai créé le site. Au lieu de publier à la racine d'un site Web (créé par un clic droit sur Sites ... Ajouter un site Web), j'ai dû créer une application (créée en cliquant avec le bouton droit sur un site Web ... Ajouter une application) et publier dans ce dossier. Notez que pour la version Core, j'ai dû changer le paramètre Version du pool d'applications .NET Framework sur "No Managed Code".

Pour moi, la solution consistait à supprimer les lignes suivantes de mon fichier web.config:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.3" newVersion="4.1.1.3" />
</dependentAssembly>
<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Tokens" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

J'ai remarqué que VS les avait ajoutés automatiquement, je ne sais pas pourquoi

Essayez cette webconfg .. remplacez "NewsApi.dll" par votre dll principale!

<?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>