c# - runallmanagedmodulesforallrequests - error http 404.0 not found iis

Página HTTP 404 no encontrada en la API web alojada en IIS 7.5

Question

Tengo una aplicación Web Api. Funciona perfectamente bien cuando lo probé utilizando el servidor de depuración VS 2010. Pero ahora lo implementé en IIS 7.5 y recibo un error HTTP 404 al intentar acceder a la aplicación.

Aquí está mi 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

¿Estás ejecutando la aplicación API web en un directorio virtual o una aplicación?

Por ejemplo: tuve el mismo problema cuando cambié mi proyecto a mi IIS local en el sitio web predeterminado> SampleWebAPI. Creo que esto se debe al cambio en el enrutamiento de URL siguiente manera:

Original: localhost:3092/api/values
Movido: localhost/SampleWebAPI/api/values

Si mueve el proyecto de la API web a su propio sitio web que se ejecuta en un puerto diferente, parece funcionar.

Nota adicional: había complicado el problema añadiendo api como el alias de una aplicación dentro de mi sitio web que causó que la URL efectiva fuera:

localhost:81/api/api/values - notado esto luego de mover el sitio web a su propio sitio web

Por lo tanto, como quería mantener una separación entre mi sitio web y el sitio web del proyecto api global.asax las reglas de enrutamiento en global.asax para la API web "DefaultAPI" de api/{controller}/{id} a {controller}/{id} y ASP.NET MVC one Default de {controller}/{id} a info/{controller}/{id} .

Answer 2

¿Qué tipo de solicitud HTTP estás haciendo?

Esta es una respuesta ligeramente de campo izquierdo, pero ¿ha intentado eliminar la página de error predeterminada de IIS para 404 para verificar qué devuelve realmente su API?

Tuve un problema por el cual quería un método de control para devolver un 404 cuando le envié la identificación incorrecta. Descubrí que siempre obtenía la página IIS 404 "Archivo o directorio no encontrado" en lugar de la respuesta HTTP de mi API. La eliminación de la página de error 404 predeterminada resolvió el problema.

Problema diferente pero nunca se sabe que puede ayudar;)

Answer 3

Algunas cosas para verificar:

1. Asegúrese de tener instalado .NET Framework 4.
2. Asegúrese de que la versión 4 de .NET Framework esté seleccionada para su sitio web y directorio virtual (si corresponde).
3. Asegúrese de tener instalado MVC o tener los archivos DLL apropiados en su directorio bin.
4. Es posible que deba permitir extensiones de servicios web ASP.NET 4.0
5. Coloque la aplicación en su propio grupo de aplicaciones.
6. Asegúrese de que el directorio tenga al menos "Scripts solamente" ejecute permisos.

Answer 4

Asegúrese de que el grupo de aplicaciones esté en modo integrado
Y agregue lo siguiente al archivo web.config:

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

Answer 5

Basado en esta respuesta SO , solo tuve que cambiar path="*." a path="*" para el ExtensionlessUrlHandler-Integrated-4.0 adicional ExtensionlessUrlHandler-Integrated-4.0 en la configuration>system.WebServer>handlers en mi web.config

Antes de:

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

Después:

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

Answer 6

Comencé a obtener respuestas 404 de la API web después de seguir un tutorial de Windows Azure que me decía que agregara un archivo "WebRole.cs" a mi proyecto.

Después de eliminar "WebRole.cs" de mi proyecto, mis llamadas a la API web comenzaron a funcionar nuevamente.

Answer 7

En mi caso, el problema era simplemente que estaba tratando de acceder al sitio en

myserver.myintranet.com/mysite

Pero el enlace del sitio web para http en IIS no tenía el nombre de host especificado en el enlace. Ya había funcionado antes y no tengo idea de cómo se deslumbró.

Una vez que puse myserver.myintranet.com en el nombre de host, el 404 desapareció.

En el Administrador de IIS, vaya a Vinculaciones ... en el panel de acciones, luego edite el enlace http para especificar el nombre de host.

Answer 8

Esta es la única respuesta que funcionó para mí ...

Tuve un problema similar ... Parecía que no importaba lo que hiciera, nada se redireccionaba y mi archivo global simplemente se ignoraba. Consideré seriamente terminarlo todo antes de encontrar esta respuesta. Espero que este enlace ayude a otros.

• : diagnóstico de errores 404 en IIS 7 y ASP.NET MVC

Agregar lo siguiente al archivo web.config funcionó para mí:

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

La etiqueta system.webServer ya estaba allí, por supuesto, pero agregué la etiqueta de los módulos y luego la etiqueta eliminar y agregar etiquetas a los módulos.

Answer 9

Esta pieza de configuración en el archivo web.config puede ayudarme si me fue útil: en la sección 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>      

Answer 10

Este problema también puede ocurrir debido a lo siguiente

1.En la Web.Config

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

2. Asegúrese de que los siguientes estén disponibles en la carpeta bin en el servidor donde se implementa la API web

• System.Net.Http

• System.Net.Http.Formatting

• System.Web.Http.WebHost

• System.Web.Http

Estos ensamblajes no se copiarán en la carpeta bin de forma predeterminada si la publicación se realiza a través de Visual Studio porque los paquetes de la API web se instalan a través de Nuget en la máquina de desarrollo. Sin embargo, si desea lograr que estos archivos estén disponibles como parte de la publicación de Visual Studio, entonces necesita configurar CopyLocal en True para estos ensamblajes.

Sadish Kumar.V

Answer 11

Existe una solución oficial de microsoft: http://support.microsoft.com/kb/980368

NO recomiendo utilizar <modules runAllManagedModulesForAllRequests = "true">. Esto lleva todas las solicitudes (incluso .jpg, .css, .pdf, etc.) serán procesadas por todos los módulos HTTP registrados. Hay dos momentos negativos: a) carga adicional en los recursos de hardware; b) posibles errores, ya que los módulos http procesarán un nuevo tipo de contenido.

Answer 12

Luché con esto, también. Mi problema exacto era que tenía un servicio web ASMX que, cuando ingresaba un parámetro en un método web y lo probé, me daba el 404. El método particular había funcionado bien en el pasado y no se había modificado, solo reeditado Luego llegué aquí y probé todas las respuestas publicadas y nada me ayudó.

¿Mi mejor solución? Sé que esto es drástico, pero acabo de crear una nueva solución de Visual Studio y un proyecto web. MVC seleccionado, luego hice un "Agregar"> "Nuevo elemento", seleccioné "Visual C #"> "Web" y "Servicio web (ASMX)" debajo de eso. Copié todo mi antiguo código de código subyacente, luego tomé nota del espacio de nombres que le dio al nuevo archivo en mi nuevo proyecto, luego pegué todo mi código anterior en el nuevo archivo de código subyacente en el nuevo proyecto y puse el espacio de nombres de regreso a lo que había sido Luego creé mis carpetas en mi proyecto que tenía antes de usar Visual Studio para hacer "Agregar"> "Nueva carpeta", luego las copié en mis archivos en las carpetas de mi otro proyecto usando el Explorador de Windows, luego hice clic derecho en cada carpeta en Visual Studio e hizo "Agregar"> "Artículo existente ..." y extrajo los elementos en esas carpetas en las carpetas de Visual Studio de mi nuevo proyecto. Volví a hacer referencia a todos mis ensamblados de .NET, teniendo ambos proyectos abiertos para poder comparar los que había referenciado anteriormente (¡tenía muchísima!). Tuve que nombrar mi nuevo proyecto ligeramente diferente, básicamente hice algo comparable a "GeneralWebApp" en lugar de "MyWebApp", por ejemplo, así que tuve que hacer un "Reemplazar todo" en toda mi solución para reemplazar ese nombre, por lo que lo haría obtener el espacio de nombres correcto para todos mis archivos. Luego hice un "Rebuild All" en el proyecto, luego lo inicié con el botón "Play" que Visual Studio da cuando lo construí correctamente. Funcionó bien Así que lo publiqué, y todo estaba bien en el servidor donde lo publiqué, cuando lo ejecuté desde allí. No tengo ninguna explicación sobre lo que sucedió, pero así fue como lo superé. No es una mala prueba solo para ver si algo que Visual Studio está haciendo lo ha arruinado.

Answer 13

No hago nada, simplemente agregue esta etiqueta en web.config, está trabajando este problema, surja uno de los siguientes puntos

1. Utilice Web Api en el mismo proyecto utilizando formularios MVC o asp.net

2. Use RouteConfig y WebApiConfig en Global.asax como GlobalConfiguration.Configure (WebApiConfig.Register); RouteConfig.RegisterRoutes (RouteTable.Routes);

3. Utilice RouteConfig para 2 propósitos, formularios asp.net usando con friendlyurl y mvc routing para enrutamiento MVC

simplemente usamos esta etiqueta en web.config, funcionará.

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

Answer 14

No te olvides de implementar global.asax

Answer 15

Pasé mucho tiempo intentando muchas cosas para finalmente darme cuenta de que estaba agregando mi aplicación web no en Sitios / Sitios web predeterminados, sino en otro sitio web enlazado a otro puerto. Obviamente, intentar localhost en el puerto 80 daría un 404.

Answer 16

Recientemente tuve un error 404 no encontrado con todas mis rutas / controladores Web Api 2. Así que fui al servidor real e intenté navegar usando localhost en lugar del nombre de host y obtuve "404.7 Not Found - El módulo de filtrado de solicitudes está configurado para denegar la extensión de archivo".

Esta publicación SO me ayuda a resolverlo.

Answer 17

Se encontró con el mismo problema con Web API y .Net Core Web API. Funcionó bien en VS 2017 durante la depuración, pero devolvió 404 cuando se publicó en IIS 7.5. La solución para mí fue cambiar la forma en que creé el sitio. En lugar de publicar en la raíz de un sitio web (creado al hacer clic derecho en Sitios ... Agregar sitio web), tuve que crear una aplicación (creada haciendo clic derecho en un sitio web ... Agregar aplicación) y publicar en esa carpeta. Tenga en cuenta que para la versión Core, tuve que cambiar la configuración de la versión de Framework .NET de Application Pool a "No Managed Code".

Answer 18

Se resolvió para mí, cuando habilito la casilla de verificación para UrlRoutingModule-4.0:

Administrador de IIS> Módulos> seleccione UrlRoutingModule-4.0> Editar módulo> active la casilla de verificación "Invocar solo para solicitudes a aplicaciones ASP.NET o controladores administrados".

Answer 19

Si IIS está instalado o habilitado después de ASP.NET, necesitará registrar manualmente ASP.NET con IIS para que su aplicación .NET funcione.

Para Windows 7 y versiones anteriores:

1. Ejecute el símbolo del sistema (cmd.exe) como administrador.
2. Navegue a la ubicación apropiada de .NET Framework. (Por ejemplo, C: / Windows / Microsoft.NET / Framework64 / v4.0.30319)
3. Ejecute aspnet_regiis.exe -i

Para Windows 8 y posterior:

1. Desde el menú de inicio, escriba "Activar o desactivar las características de Windows" y seleccione el primer resultado.
2. Expanda Internet Information Services: World Wide Web Services: características de desarrollo de aplicaciones y seleccione ASP.NET 4.5 (o ASP.NET 3.5 si necesita admitir proyectos en .NET Framework 2.0-3.5).
3. Haga clic en Aceptar.

Answer 20

También encontré este problema. Resolví el problema yendo a Application Pools> Application Pool Name y cambié .NET Framework de la versión v.2.0.50727 a v4.0.30319.

Answer 21

Tenía el mismo problema. Esta configuración ha resuelto el problema.

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

Como se explica en http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html solución anterior debe evitarse. Use esto en su lugar. La misma solución es proporcionada por Lopsided también. Mantenerlo aquí para que los usuarios eviten implementar la primera solución de trabajo.

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

Answer 22

Tuve el mismo problema, una respuesta 404 para los controladores de API web cuando se sirve desde el IIS, pero todo funcionó bien desde VS2010. Ninguna de las soluciones anteriores funcionó para mí. Finalmente, descubrí que el problema era que agregamos compatibilidad con WSE 3.0 para la aplicación y el DLL de Microsoft.Web.Services3 faltaba en el directorio / bin de la aplicación. Extraño, pero después de copiar el dll, la asignación de ruta comenzó a funcionar.

Answer 23

Tuve el mismo problema: en una máquina recién instalada con Visual Studio 2013, el proyecto de API web funcionaba bajo IISExpress, pero no bajo IIS local. Intenté todo lo que pude encontrar, pero al final el problema no fue necesario con la API web, pero con MVC: incluso si se instaló, no se estaba ejecutando ningún proyecto MVC.

Lo que funcionó para mí fue desinstalar IIS (de ADD / REMOVE Windows Features), luego reinstalarlo, y luego ejecutar aspnet_regiis -i. Quizás esto ayude a alguien más.

Answer 24

Tuve que desactivar la Opción de publicación de archivos "Precompilar durante la publicación".

Answer 25

Tuve un problema similar. Tenía la configuración correcta en mi archivo web.config, pero estaba ejecutando el grupo de aplicaciones en modo clásico en lugar de modo integrado

Answer 26

Yo estaba luchando con esto también. Afortunadamente, Steve Michelotti documentó una solución que funcionó para mí here .

Al final del día, habilité todos los verbos (verb = "*") al controlador ExtensionlessUrlHandler-Integrated-4.0 en mi configuración 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>

Otros han señalado que tener WebDAV habilitado causa problemas. Afortunadamente, no me encontré con ese problema también.