web-dev-qa-db-fra.com

L'application API Web ASP.NET donne 404 lorsqu'elle est déployée à IIS 7

J'ai une API Web ASP.NET qui fonctionne correctement lors de l'exécution sur "IIS Express" avec localhost: 1783

Settings in VS

Mais lorsque je décroise "Utiliser IIS Express" puis que je clique sur "Créer un répertoire virtuel" ...

New settings

... Je viens de recevoir 404 erreurs: The 404 error

Des idées ce qui ne va pas? Merci!

asp.netiis-7asp.net-web-api
51
Cotten

Bien que la réponse indiquée le fasse fonctionner, tout ce que vous avez vraiment besoin d'ajouter à la configuration Web est:

    <handlers>
      <!-- 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=""/>
    </handlers>

Notez qu'aucun d'entre eux n'a un ordre particulier, bien que vous souhaitiez que vos suppressions soient supprimées avant vos ajouts.

La raison pour laquelle nous finissons par obtenir un 404 est que le module de routage d’URL n’intervient que pour la racine du site Web dans IIS. En ajoutant le module à la configuration de cette application, le module s'exécute sous le chemin de cette application (votre chemin de sous-répertoire), et le module de routage démarre.

38
DavidAndroidDev

Pour moi, en plus d'avoir runAllManagedModulesForAllRequests="true", j'ai également dû modifier l'attribut "path".__ ci-dessous. Auparavant, mon attribut path était "*.", ce qui signifie qu'il n'était exécuté que sur les URL contenant un point Cependant, l'URL de mon application ne contient pas de point. Quand j'ai changé de chemin en "*", cela a fonctionné ... Voici ce que j'ai maintenant:

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

Vous devrez peut-être installer le correctif KB980368 . 

Cet article décrit une mise à jour qui permet à certains gestionnaires d'Internet Information Services (IIS) 7.0 ou IIS 7.5 de gérer les demandes dont les URL ne se terminent pas par un point. Plus précisément, ces gestionnaires sont mappés sur "". chemins de demande. Actuellement, un gestionnaire mappé sur un "." Le chemin de demande traite uniquement les demandes dont les URL se terminent par un point. Par exemple, le gestionnaire traite uniquement les demandes dont les URL ressemblent à l'URL suivante:

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

Après avoir appliqué cette mise à jour, les gestionnaires mappés sur un "*". request path peut gérer les demandes dont les URL se terminent par un point et celles dont les URL ne se terminent pas par un point. Par exemple, le gestionnaire peut désormais gérer des demandes ressemblant aux URL suivantes:

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

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

Une fois ce correctif appliqué, les applications ASP.NET 4 peuvent gérer les demandes d’URL sans extension. Par conséquent, les HttpModules gérés qui s'exécutent avant l'exécution du gestionnaire s'exécutent. Dans certains cas, les HttpModules peuvent renvoyer des erreurs pour des URL sans extension. Par exemple, un HttpModule qui a été écrit pour n'attendre que des demandes .aspx peut maintenant renvoyer des erreurs lorsqu'il tente d'accéder à la propriété HttpContext.Session.

10
Tony

Ce problème peut également se produire en raison des problèmes suivants: 

1. Dans le Web.Config

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

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

• System.Net.Http

• System.Net.Http.Formatting

• System.Web.Http.WebHost

• System.Web.Http

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

8
Sadish Kumar V

Certaines personnes disent que runAllManagedModulesForAllRequests = "true" aura des problèmes de performances et des problèmes de routage MVC . Ils suggèrent d'utiliser les éléments suivants:

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

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

2
Jeff

Pour moi, ce problème était légèrement différent des autres réponses, car je ne recevais que des 404 sur OPTIONS, et pourtant j'avais déjà des options spécifiées dans mes options de gestionnaire d'URL intégré sans extension. Très perturbant.

  1. Comme d'autres l'ont déjà indiqué, runAllManagedModulesForAllRequests = "true" dans le nœud modules est un moyen facile de résoudre globalement la plupart des problèmes liés à l'API Web 404 - bien que je préfère la réponse de @DavidAndroidDev, qui est beaucoup moins intrusive. Mais il y avait quelque chose de plus dans mon cas.
  2. Malheureusement, cet élément était défini dans IIS sous Demande de filtrage dans le site:

 OPTIONS Issue with Request Filtering

En ajoutant le nœud security suivant au fichier web.config, il était nécessaire de supprimer ce problème - un fichier system.webserver complet inclus pour le contexte:

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

Bien que ce ne soit pas la réponse parfaite à cette question, il s’agit du premier résultat de "IIS OPTIONS 404" sur Google. J'espère donc que cela aidera quelqu'un; m'a coûté une heure aujourd'hui. 

0
Moby's Stunt Double

En ce qui me concerne, j'ai reçu une erreur 404 sur mes sites Web N'UTILISANT PAS IIS Express (à l'aide de IIS local) lors de l'exécution d'une application WAS utilisant IIS Express. Si je fermais le navigateur utilisé pour exécuter IIS Express, le 404 disparaîtrait. Pour moi, mon projet IIS Express appelait des services locaux IIS. J'ai donc converti le projet IIS Express pour utiliser Local IIS, puis tout a fonctionné. Il semble que vous ne puissiez pas exécuter simultanément un site Web non-IIS Express et un site Web local IIS pour une raison quelconque.

0
deadlydog

Je lutte contre ce problème depuis quelques jours en essayant toutes sortes de choses suggérées. Ma machine dev fonctionnait bien, mais la nouvelle machine sur laquelle je déployais me donnait l'erreur 404. 

Dans IIS manager, j'ai comparé les mappages de gestionnaires sur les deux machines afin de réaliser que de nombreux gestionnaires manquaient. Il s'avère que ASP.Net 5 n'était pas installé sur la machine. 

0
yannb

Si vous utilisez Visual Studio 2012, téléchargez et installez la mise à jour 2 récemment publiée par Microsoft (à la date du 4/2013).

Mise à jour 2 de Visual Studio 2012

Cette mise à jour contient des corrections de bogues liées au problème.

0
mitaka

J'ai eu le même problème. J'ai trouvé beaucoup de problèmes de R & D.

mais tant que votre configuration est finie, cela signifie que aspnet 64 bit et le IIS bien alors le seul problème que j’ai vu est le chemin "web api prenant le chemin local direct" de sorte que vous avez besoin de le regarder. par comme ceci .. ~ ../../../ api/products/

merci beaucoup d'avoir posté le problème. je leanred alot environ IIS et d'autres paramètres dans le fichier de configuration.

0
SRIRAM