OwinStartup no disparar

Respuesta alternativa al problema original discutido - Owin "no disparar."En mi caso, pasé horas pensando que no estaba disparando debido a que no podía establecer un punto de interrupción en él.

Al depurar el inicio de OWIN en visual studio

• IIS Express-Ejecutar " F5 " se romperá en el código de inicio de OWIN

• IIS-Ejecutar" F5 " no se romperá hasta después de OWIN (y global.asax) el código está cargado. Si se adjunta a W3P.exe usted será capaz de entrar en se.

Si ha actualizado desde una versión anterior de MVC, asegúrese de que no tiene

  <add key="owin:AutomaticAppStartup" value="false" />

En su web.config. Suprimirá la llamada a la lógica de inicio.

En su lugar cámbialo a true

  <add key="owin:AutomaticAppStartup" value="true" />

Me doy cuenta de que ya mencionaste esto, pero a veces la gente (como yo) no lee toda la pregunta y simplemente salta a las respuestas...

En algún lugar a lo largo de la línea - cuando actualicé a MVC 5 esto se agregó y nunca lo vi hasta hoy.

Si tiene problemas para depurar el código en la clase Startup, también he tenido este problema, o pensé que lo tenía. El código se estaba disparando, pero creo que sucede antes de que el depurador se haya adjuntado, por lo que no puede establecer puntos de interrupción en el código y ver lo que está sucediendo.

Puede probar esto lanzando una excepción en el método Configuration de la clase Startup.

Tuve un problema similar a este y la compensación Temporal ASP.NET Los archivos lo arreglaron. Espero que esto ayude a alguien.

CONSEJOS DE DEPURACIÓN

Si la depuración no funciona, intente usar IIS Express o pruebe el método siguiente para IIS local

Uso de IIS locales

Por alguna razón este método habilita la depuración de este método:

1. Solicitar una página web
2. Adjuntar a w3wp.proceso exe
3. Toca la web.archivo de configuración
4. Solicitar una página web

Consejo adicional

Tal vez haciendo esto se vaciará un caché:

1. En web.config agregue el atributo optimizeCompilations con un valor falso

2. Ejecutar sitio

3. Deshacer el cambio en web.config

Yo tenía el mismo problema. Microsoft.Owin.Host.El paquete SystemWeb fue instalado pero durante la instalación NuGet no pudo agregar el dll como referencia por alguna razón. Asegúrate de que tu proyecto tenga esa referencia. Si no puedes intentar reinstalar:

update-package Microsoft.Owin.Host.SystemWeb -reinstall

Tuve un error como el siguiente en reinstalar pero de alguna manera funcionó:

Falló la llamada al sistema. (Excepción de HRESULT: 0x80010100 (RPC_E_SYS_CALL_FAILED))

En mi caso, el grupo de aplicaciones de IIS no se estableció en v4. Era v2.

Cambió el AppPool a v4 y todo estaba bien.

En mi caso este Microsoft.Owin.Host.El paquete SystemWeb está presente en el proyecto.

Pero debajo de dos etiquetas no están presentes en la web.config.

<add key="owin:AutomaticAppStartup" value="true" />
<add key="owin:appStartup" value="namespace.className.methodName" />

Después de añadirlos funciona sin problemas.

En mi caso, la ruta de salida de mi sitio web es cambiada por alguien, el IIS Express incluso no carga OWIN, y la clase setup no será golpeada por supuesto. Después de establecer la ruta de salida como " bin\", funciona bien.

Tuve el mismo problema cuando agregué Owin a un proyecto web existente. Finalmente descubrí que el problema se debía a lo siguiente en la web.archivo de configuración.

<assemblies>
  <remove assembly="*" />
  <add assembly="System.Web.Mvc" />
  <add assembly="System.Web.WebPages" />

   ...

</assemblies>

El remove assembly="*" estaba causando el problema. Cuando elimino esta línea se ejecutó el código de inicio de Owin. Finalmente lo cambio a lo siguiente y funcionó perfectamente

<assemblies>
  <remove assembly="*" />
  <add assembly="Microsoft.Owin.Host.SystemWeb" />
  <add assembly="System.Web.Mvc" />
  <add assembly="System.Web.WebPages" />
  <add assembly="System.Web.Helpers" />
...
</assemblies>

Me metí con muchas de las sugerencias en este post.

Tenía lo siguiente, pero todavía no podía aterrizar en un punto de quiebre. Lanzar una excepción demostró que se estaba introduciendo el código.

<appSettings>
...
  <add key="owin:AutomaticAppStartup" value="true" />
  <add key="owin:appStartup" value="SSOResource.Startup, SSOResource" />
...
</appSettings>

Finalmente, por desesperación, miré project - >properties, y luego en la sección WEB también revisé la casilla de verificación CÓDIGO NATIVO (ASP.NET debe ser ya comprobado).

Eso finalmente lo arregló para mí.

Nota: Estoy usando Visual Studio 2017 Profesional.

No estoy seguro de si esto todavía ayudará a alguien, pero he hecho todas las soluciones anteriores (y de algunos otros mensajes) en vano.

Lo que solucionó el problema en mi extremo fue poner una barra invertida al final del valor RedirectUri en la web.config (loco, lo sé!). RedirectUri es un parámetro en UseOpenIdConnectAuthentication.

Entonces, en lugar de:

<add key="ida:RedirectUri" value="https://www.bogussite.com/home" />

Haz esto:

<add key="ida:RedirectUri" value="https://www.bogussite.com/home/" />

Y también se actualizó la URL de respuesta en la configuración de la aplicación Azure.

Que de alguna manera hizo el inicio se ejecutará como se esperaba (probablemente se borró algo de caché), y los puntos de interrupción ahora se están disparando.

FYI. Estaba modelando mi código desde aquí: https://github.com/microsoftgraph/aspnet-connect-sample

Después de convertir una biblioteca de clases en un Proyecto de Aplicación Web, me encontré con esto y me volví terco. Resultó que, en mi archivo .csProj, tenía esto:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  <DebugSymbols>true</DebugSymbols>
  <DebugType>full</DebugType>
  <Optimize>false</Optimize>
  <OutputPath>bin\Debug\</OutputPath>
  <DefineConstants>DEBUG;TRACE</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  <DebugType>pdbonly</DebugType>
  <Optimize>true</Optimize>
  <OutputPath>bin\Release\</OutputPath>
  <DefineConstants>TRACE</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
</PropertyGroup>

• construyendo así las diversas dll en una subcarpeta de la carpeta bin (que ifc. no funcionará). La solución fue cambiar ambos contenidos de texto para OutputPath a solo bin\.

Para mí fue porque no están en el mismo espacio de nombres. Después de quitar mi AppStart de " proyecto.Inicio.AppStart " y dejar que ambos se inicien.cs y Startup.Auth.cs con " proyecto.Startup " namespace, todo volvió a funcionar perfectamente.

Espero que ayude!

En mi caso, mi web.config had

<authorization>
  <allow users="?" />
</authorization>

Para forzarlo a volver a Owin, necesitaba que fuera

<authorization>
  <deny users="*" />
</authorization>

Si ve este problema con el alojamiento de IIS, pero no al depurar F5, intente crear una nueva aplicación en IIS.

Esto lo arregló para mí. (windows 10) Al final borré la aplicación IIS "mala" y recreé una idéntica con el mismo nombre.

Creo que lo que algunas personas estaban tratando de llegar a lo anterior es que si desea hacer que su servidor OWIN "cobre vida" programáticamente, estaría llamando a algo como esto:

using Microsoft.Owin.Hosting;

    IDisposable _server = WebApp.Start<StartupMethod>("http://+:5000"); 
              // Start Accepting HTTP via all interfaces on port 5000

Una vez que realice esta llamada, verá que la llamada a StartupMethod() se dispara en el depurador

Primero agregue la clase OWIN Auth y luego habilite la clave OWIN:AutomaticAppStartup en su web.config like Ahora se disparará