OwinStartup ne se déclenche pas

J'ai eu le code de configuration OwinStartup fonctionnant parfaitement, puis il a cessé de fonctionner. Malheureusement, je ne sais pas exactement ce que j'ai fait pour que cela cesse de fonctionner et j'ai vraiment du mal à le comprendre.

Pour m'assurer d'avoir les bases couvertes, j'ai vérifié deux fois pour m'assurer que j'ai le

[assembly:OwinStartup(typeof(WebApplication.Startup))] 

attribut correctement attribué et vérifié que je n'ai pas d'appSetting pour owin: AutomaticAppStartup défini sur false, j'ai donc défini un ensemble sur true pour être sûr car il n'y avait rien auparavant.

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

J'ai également essayé d'appeler spécifiquement l'application

<add key="owin:appStartup" value="WebApplication.Startup" />

Avant qu'il ne cesse de fonctionner, j'ai mis à niveau les packages Microsoft.Owin.Security NuGet vers 2.0.2, j'ai donc essayé de les rétablir en 2.0.1 (ce qui était pénible) mais cela n'a rien changé. J'ai installé WebActivator sur le projet et je l'utilise pour démarrer d'autres choses, mais je l'ai testé sur un nouveau modèle WebApplication et cela fonctionne là-bas, donc je ne pense pas que ce soit le coupable.

J'ai également essayé de supprimer ma classe de démarrage et d'utiliser Visual Studio pour en ajouter une nouvelle en utilisant le type de classe de démarrage OWIN dans Ajouter un nouvel élément et qui n'est pas appelé non plus. Ensuite, j'ai essayé d'ajouter une deuxième classe Startup car je sais qu'elle lèvera une exception s'il y a plus d'un attribut OwinStartup défini, mais il ne lance aucune exception à cet endroit.

Je ne sais pas quoi d'autre à essayer. Des pensées?

Mise à jour

Il s'avère que Resharper a supprimé la référence à Microsoft.Owin.Host.SystemWeb lorsque je l'ai utilisé pour supprimer les références inutilisées.

Assurez-vous que vous avez installé le Microsoft.Owin.Host.SystemWebpackage dans le projet. Ce package est nécessaire pour la détection de démarrage dans les applications hébergées IIS. Pour plus d'informations, vous pouvez vous référer à cet article .

Si vous avez effectué une mise à niveau à partir d'une ancienne version de MVC, assurez-vous que vous n'avez pas

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

dans votre web.config. Il supprimera l'appel de la logique de démarrage.

Au lieu de cela, changez-le en true

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

Je sais que vous l'avez déjà mentionné, mais parfois les gens (comme moi) ne lisent pas toute la question et sautent juste aux réponses ...

Quelque part le long de la ligne - lorsque je suis passé à MVC 5, cela a été ajouté et je ne l'ai jamais vu jusqu'à aujourd'hui.

Réponse alternative au problème d'origine discuté - Owin "ne tire pas". Dans mon cas, j'ai passé des heures à penser qu'il ne tirait pas car je ne pouvais pas y définir de point d'arrêt.

Lors du débogage du démarrage OWIN dans Visual Studio

• IIS Express - L'exécution de "F5" s'arrêtera sur le code de démarrage OWIN

• IIS - L'exécution de "F5" ne s'arrêtera qu'après le chargement du code OWIN (et global.asax). Si vous vous connectez à W3P.exe, vous pourrez y accéder.

Si vous rencontrez des problèmes pour déboguer le code dans la Startupclasse, j'ai également eu ce problème - ou je pensais que oui. Le code était en train de se déclencher, mais je pense que cela se produit avant que le débogueur ne se connecte, vous ne pouvez donc pas définir de points d'arrêt sur le code et voir ce qui se passe.

Vous pouvez le prouver en lançant une exception dans la Configurationméthode de la Startupclasse.

CONSEILS DE DÉBOGAGE

Si le débogage ne fonctionne pas, essayez d'utiliser IIS Express ou essayez la méthode ci-dessous pour IIS local

Utilisation d'IIS local

Pour une raison quelconque, cette méthode permet le débogage de cette méthode:

1. Demander une page Web
2. Attacher au processus w3wp.exe
3. Appuyez sur le fichier web.config
4. Demander une page Web

Astuce supplémentaire

Peut-être que cela videra un cache:

5. Dans web.config, ajoutez l'attribut OptimizeCompilations avec une fausse valeur

   <compilation debug = "true" ... OptimizeCompilations = "false">

6. Exécuter le site

7. Annuler la modification dans web.config

J'ai eu un problème similaire à cela et la suppression des fichiers temporaires ASP.NET l'a corrigé. J'espère que cela aide quelqu'un.

J'ai eu le même problème. Le package Microsoft.Owin.Host.SystemWeb a été installé mais pendant l'installation, NuGet n'a pas pu ajouter la DLL comme référence pour une raison quelconque. Assurez-vous que votre projet a cette référence. Sinon, vous pouvez essayer de réinstaller:

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

J'ai eu une erreur comme ci-dessous lors de la réinstallation, mais cela a fonctionné:

L'appel système a échoué. (Exception de HRESULT: 0x80010100 (RPC_E_SYS_CALL_FAILED))

Dans mon cas, le pool d'applications IIS n'était pas défini sur v4. C'était v2.

Changé l'AppPool en v4 et tout allait bien.

J'ai eu le même problème lorsque j'ai ajouté Owin à un projet Web existant. J'ai finalement trouvé que le problème était dû à ce qui suit dans le fichier web.config.

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

   ...

</assemblies>

L'assembly de suppression = "*" était à l'origine du problème. Lorsque je supprime cette ligne, le code de démarrage Owin s'est exécuté. Je l'ai finalement changé comme suit et cela a parfaitement fonctionné

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

Dans mon cas, le chemin de sortie de mon site Web est modifié par quelqu'un, IIS Express ne charge même pas OWIN et la classe d'installation ne sera pas atteinte bien sûr. Après avoir défini le chemin de sortie comme "bin \", cela fonctionne bien.

Dans mon cas, ce package Microsoft.Owin.Host.SystemWeb est présent dans le projet.

Mais ci-dessous, deux balises ne sont pas présentes dans web.config.

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

après les avoir ajoutés, cela fonctionne bien.

Dans mon cas, mon web.config avait

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

Pour le forcer à se replier sur Owin, j'avais besoin qu'il soit

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

J'ai joué avec beaucoup de suggestions sur ce post.

J'avais ce qui suit mais je ne pouvais toujours pas atterrir sur un point d'arrêt. Le fait de lever une exception a prouvé que le code était entré.

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

Enfin, par désespoir, j'ai regardé le projet-> propriétés, puis sous la section WEB, j'ai également coché la case NATIVE CODE (ASP.NET devrait déjà être coché).

Cela m'a finalement arrangé.

Remarque: j'utilise Visual Studio 2017 Professional.

Je ne sais pas si cela aidera toujours quelqu'un, mais j'ai fait toutes les solutions ci-dessus (et à partir d'autres postes) en vain.

Ce qui a résolu le problème de mon côté, c'était de mettre une barre oblique inverse à la fin de la valeur RedirectUri dans le web.config (fou, je sais!). RedirectUri est un paramètre dans UseOpenIdConnectAuthentication.

Donc, au lieu de:

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

Faites ceci:

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

Et également mis à jour l'URL de réponse dans les paramètres de l'application Azure.

Cela a en quelque sorte fait démarrer le démarrage comme prévu (probablement vidé un cache), et les points d'arrêt se déclenchent maintenant.

Pour info. Je modélisais mon code à partir d'ici: https://github.com/microsoftgraph/aspnet-connect-sample

Après avoir converti une bibliothèque de classes en projet d'application Web , je suis tombé sur cela et suis devenu têtu. Il s'est avéré, dans mon .csProjdossier, j'avais ceci:

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

• construisant ainsi les diverses DLL dans un sous-dossier du dossier bin (qui ifc. ne fonctionnera pas). La solution consistait à changer le contenu du texte pour OutputPathjuste bin\.

Pour moi, c'est parce qu'ils ne sont pas dans le même espace de noms. Après avoir supprimé mon AppStart de "project.Startup.AppStart" et les avoir laissé à la fois Startup.cs et Startup.Auth.cs avec l'espace de noms "project.Startup", tout était à nouveau parfaitement fonctionnel.

J'espère que ça aide!

Si vous rencontrez ce problème avec l'hébergement IIS, mais pas lors du débogage F5, essayez de créer une nouvelle application dans IIS.

Cela m'a arrangé. (Windows 10) À la fin, j'ai supprimé la "mauvaise" application IIS et en ai recréé une identique avec le même nom.

Je pense que ce que certaines personnes essayaient de voir ci-dessus, c'est que si vous voulez que votre serveur OWIN "prenne vie" par programmation, vous appelleriez quelque chose comme ceci:

using Microsoft.Owin.Hosting;

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

Une fois que vous avez effectué cet appel, vous verrez l'appel à StartupMethod () se déclencher dans le débogueur

J'ai trouvé l'article suivant très utile:

https://weblog.west-wind.com/posts/2015/Apr/29/Adding-minimal-OWIN-Identity-Authentication-to-an-Existing-ASPNET-MVC-Application#MinimalCodeSummary

Dans mon cas, j'ai dû définir les éléments suivants avant que l'authentification Owin ne fonctionne au lieu de l'authentification Windows:

<system.web>   
    <authentication mode="None" />   
<system.web>

Cela a fonctionné pour moi:

ajouter le mode d'authentification = "Aucun"

<system.web>
    <compilation debug="true" targetFramework="4.6.1" />
    <httpRuntime targetFramework="4.6.1" />
      <authentication mode="None" /><!--Use OWIN-->
  </system.web>

Ajoutez d'abord la classe d'authentification OWIN, puis activez OWIN: AutomaticAppStartup clé dans votre web.config comme Maintenant ça va tirer