OwinStartup wird nicht ausgelöst

Question

Ich hatte den OwinStartup-Konfigurationscode perfekt funktionieren und dann hat er aufgehört zu funktionieren. Leider bin ich mir nicht genau sicher, was ich getan habe, um ihn zum Stoppen zu bringen, und ich habe wirklich Schwierigkeiten, es herauszufinden.

Um sicherzustellen, dass ich die Grundlagen abgedeckt habe, habe ich mehrfach überprüft, ob ich die

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

Attribut richtig zugewiesen habe und darauf geachtet, dass ich kein appSetting für owin:AutomaticAppStartup habe, das auf false gesetzt ist, also habe ich eins auf true gesetzt, um sicher zu gehen, da vorher nichts vorhanden war.

Ich habe auch versucht, das appSetting speziell anzugeben:

Vor dem Stopp habe ich die Microsoft.Owin.Security NuGet-Pakete auf 2.0.2 aktualisiert, also habe ich versucht, sie auf 2.0.1 zurückzusetzen (das war eine Qual), aber es hat nichts geändert. Ich habe WebActivator im Projekt installiert und verwende es, um andere Dinge zu initialisieren, aber ich habe das auf einer frischen WebApplication-Vorlage getestet und es funktioniert dort, also denke ich nicht, dass das der Übeltäter ist.

Ich habe auch versucht, meine Startup-Klasse zu entfernen und Visual Studio zu verwenden, um eine neue hinzuzufügen, indem ich den OWIN Startup-Klassentyp in Neues Element hinzufüge, und auch das wird nicht aufgerufen. Als nächstes habe ich versucht, eine zweite Startup-Klasse hinzuzufügen, da ich weiß, dass eine Ausnahme geworfen wird, wenn mehr als ein OwinStartup-Attribut definiert ist, aber dort wird keine Ausnahme geworfen.

Nicht sicher, was ich noch ausprobieren soll. Irgendwelche Gedanken?

Update

Es stellte sich heraus, dass Resharper den Verweis auf Microsoft.Owin.Host.SystemWeb entfernt hat, als ich ihn benutzte, um nicht verwendete Verweise zu entfernen.

Answer 1

Falls Sie mehrere Hosts in Ihrer Lösung verwenden, die denselben Namensraum nutzen, stellen Sie sicher, dass sie auf einem separaten IISExpress-Port laufen (und löschen Sie den .vs-Ordner und starten Sie vs neu).

Answer 2

Wenn Sie dieses Problem bei der IIS-Hosting sehen, aber nicht beim F5-Debuggen, versuchen Sie, eine neue Anwendung in IIS zu erstellen.

Dies hat es für mich behoben. (Windows 10) Am Ende habe ich die "schlechte" IIS-Anwendung gelöscht und eine identische mit dem gleichen Namen neu erstellt.

Answer 3

Für mich lag es daran, dass sie sich nicht im gleichen Namespace befinden. Nachdem ich meinen AppStart von "project.Startup.AppStart" entfernt habe und sowohl Startup.cs als auch Startup.Auth.cs mit dem Namespace "project.Startup" belassen habe, hat alles wieder perfekt funktioniert.

Ich hoffe, es hilft!

Answer 4

Nachdem ich eine Klassenbibliothek in ein Webanwendungsprojekt umgewandelt habe, bin ich auf dieses Problem gestoßen und wurde hartnäckig. Es stellte sich heraus, dass in meiner .csProj-Datei dies stand:

  true
  full
  false
  bin\Debug\
  DEBUG;TRACE
  prompt
  4

  pdbonly
  true
  bin\Release\
  TRACE
  prompt
  4

• Dadurch wurden die verschiedenen DLLs in einen Unterordner des Bin-Ordners kompiliert (was nicht funktionieren wird). Die Lösung bestand darin, den Inhalt für OutputPath in beiden PropertyGroups einfach auf bin\ zu ändern.

Answer 5

Ich bin mir nicht sicher, ob das noch jemandem hilft, aber ich habe alle oben genannten Lösungen ausprobiert (und auch aus einigen anderen Beiträgen), jedoch ohne Erfolg.

Was das Problem bei mir behoben hat, war ein Backslash am Ende des Wertes von RedirectUri in der web.config (verrückt, ich weiß!). RedirectUri ist ein Parameter in UseOpenIdConnectAuthentication.

Also, anstatt:

Tun Sie dies:

Und aktualisieren Sie die Antwort-URL in den Azure App-Einstellungen ebenfalls.

Das hat dazu geführt, dass der Startvorgang wie erwartet abläuft (vermutlich wurde irgendein Cache geleert) und die Breakpoints werden jetzt ausgelöst.

Zur Info. Ich habe meinen Code von hier modelliert: https://github.com/microsoftgraph/aspnet-connect-sample