OwinStartup nie strzela

Kod OwinStartup działał idealnie, a potem przestał działać. Niestety nie jestem pewien, co dokładnie zrobiłem, aby przestał działać i naprawdę trudno mi to rozgryźć.

Aby upewnić się, że mam podstawy, dwukrotnie sprawdziłem, aby upewnić się, że mam

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

atrybut przypisany poprawnie i upewniłem się, że nie mam appSetting for owin: AutomaticAppStartup, który jest ustawiony na false, więc ustawiłem jeden na true, aby był bezpieczny, ponieważ wcześniej nic tam nie było.

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

Próbowałem także specjalnie wywołać aplikację:

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

Zanim przestał działać, zaktualizowałem pakiety NuGet Microsoft.Owin.Security do wersji 2.0.2, więc próbowałem przywrócić je do wersji 2.0.1 (to był problem), ale nic to nie zmieniło. Mam WebActivator zainstalowany w projekcie i używam go do ładowania innych rzeczy, ale przetestowałem to na nowym szablonie WebApplication i działa tam, więc nie sądzę, że to winowajca.

Próbowałem także usunąć moją klasę startową i użyć programu Visual Studio, aby dodać nową, używając typu klasy startowej OWIN w Dodaj nowy element, ale to też nie jest wywoływane. Następnie próbowałem dodać drugą klasę uruchamiania, ponieważ wiem, że zgłosi wyjątek, jeśli zdefiniowano więcej niż jeden atrybut OwinStartup, ale nie zgłasza tam żadnego wyjątku.

Nie jestem pewien, co jeszcze spróbować. jakieś pomysły?

Aktualizacja

Okazuje się, że Resharper usunął odwołanie do Microsoft.Owin.Host.SystemWeb, kiedy użyłem go do usunięcia nieużywanych odniesień.

Upewnij się, że masz zainstalowany Microsoft.Owin.Host.SystemWebpakiet w projekcie. Ten pakiet jest potrzebny do wykrywania uruchamiania w aplikacjach hostowanych w IIS. Więcej informacji można znaleźć w tym artykule .

Jeśli dokonałeś aktualizacji ze starszej wersji MVC, upewnij się, że nie masz

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

w twoim web.config. Pominie to wywoływanie logiki uruchamiania.

Zamiast tego zmień na true

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

Zdaję sobie sprawę, że już o tym wspomniałeś, ale czasami ludzie (jak ja) nie czytają całego pytania i po prostu przeskakują do odpowiedzi ...

Gdzieś wzdłuż linii - kiedy uaktualniłem do MVC 5, to zostało dodane i nigdy tego nie widziałem.

Alternatywna odpowiedź na omawiany pierwotny problem - Owin „nie strzela”. W moim przypadku spędziłem godziny, myśląc, że to nie strzelał, ponieważ nie byłem w stanie ustawić w nim punktu przerwania.

Podczas debugowania uruchamiania OWIN w Visual Studio

• IIS Express - Uruchomienie „F5” spowoduje uszkodzenie kodu startowego OWIN

• IIS - Uruchomienie „F5” nie ulegnie awarii, dopóki nie zostanie załadowany kod OWIN (i global.asax). Jeśli podłączysz się do W3P.exe, będziesz mógł do niego wejść.

Jeśli masz problemy z debugowaniem kodu w Startupklasie, również miałem ten problem - lub tak mi się zdawało. Kod był uruchamiany, ale wierzę, że dzieje się to przed dołączeniem debugera, więc nie można ustawić punktów przerwania w kodzie i zobaczyć, co się dzieje.

Możesz to udowodnić, zgłaszając wyjątek w Configurationmetodzie Startupklasy.

WSKAZÓWKI DOTYCZĄCE DEBUGOWANIA

Jeśli debugowanie nie działa, spróbuj użyć IIS Express lub wypróbuj poniższą metodę dla lokalnych IIS

Korzystanie z lokalnych usług IIS

Z jakiegoś powodu ta metoda umożliwia debugowanie tej metody:

1. Poproś o stronę internetową
2. Dołącz do procesu w3wp.exe
3. Dotknij pliku web.config
4. Poproś o stronę internetową

Dodatkowa wskazówka

Może zrobienie tego spowoduje opróżnienie pamięci podręcznej:

5. W pliku web.config dodaj atrybut optimizeCompilations z wartością false

   <kompilacja debug = "true" ... optimizeCompilations = "false">

6. Uruchom witrynę

7. Cofnij zmianę w pliku web.config

Miałem podobny problem i usunięcie tymczasowych plików ASP.NET to rozwiązało. Mam nadzieję, że to komuś pomoże.

Miałem ten sam problem. Pakiet Microsoft.Owin.Host.SystemWeb został zainstalowany, ale podczas instalacji NuGet z jakiegoś powodu nie mógł dodać biblioteki dll jako odniesienia. Upewnij się, że Twój projekt ma takie odniesienie. Jeśli nie, możesz spróbować zainstalować ponownie:

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

Miałem błąd jak poniżej przy ponownej instalacji, ale jakoś to zadziałało:

Wywołanie systemowe nie powiodło się. (Wyjątek od HRESULT: 0x80010100 (RPC_E_SYS_CALL_FAILED))

W moim przypadku pula aplikacji IIS nie została ustawiona na v4. To było v2.

Zmieniłem AppPool na v4 i wszystko było w porządku.

Miałem ten sam problem, kiedy dodałem Owin do istniejącego projektu internetowego. W końcu odkryłem, że problem był spowodowany przez następujące w pliku web.config.

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

   ...

</assemblies>

Usunięcie zestawu = „*” było przyczyną problemu. Kiedy usuwam ten wiersz, uruchamiany jest kod startowy Owin. W końcu zmieniłem to na następujące i działało idealnie

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

W moim przypadku ścieżka wyjściowa mojej witryny jest przez kogoś zmieniana, IIS Express nawet nie ładuje OWIN, a klasa instalacyjna oczywiście nie zostanie trafiona. Po ustawieniu ścieżki wyjściowej jako „bin \” działa to dobrze.

W moim przypadku ten pakiet Microsoft.Owin.Host.SystemWeb jest obecny w projekcie.

Ale poniżej dwóch tagów nie ma w pliku web.config.

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

po ich dodaniu działa płynnie.

W moim przypadku mój web.config miał

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

Musiałem to zrobić, aby zmusić go do powrotu do Owina

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

Pomieszałem z wieloma sugestiami dotyczącymi tego postu.

Miałem następujące, ale nadal nie mogłem wylądować w punkcie krytycznym. Zgłoszenie wyjątku potwierdziło, że kod jest wprowadzany.

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

W końcu z desperacji spojrzałem na właściwości project>, a następnie w sekcji WEB zaznaczyłem również pole wyboru NATIVE CODE (ASP.NET powinien być już zaznaczony).

To ostatecznie mnie naprawiło.

Uwaga: używam programu Visual Studio 2017 Professional.

Nie jestem pewien, czy to nadal komuś pomoże, ale zrobiłem wszystkie powyższe rozwiązania (i niektóre inne posty) bezskutecznie.

Tym, co naprawiło problem po mojej stronie, było umieszczenie odwrotnego ukośnika na końcu wartości RedirectUri w pliku web.config (szalone, wiem!). RedirectUri jest parametrem w UseOpenIdConnectAuthentication.

Zamiast więc:

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

Zrób to:

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

I zaktualizowałem również adres URL odpowiedzi w ustawieniach aplikacji Azure.

To w jakiś sposób sprawiło, że Autostart działał zgodnie z oczekiwaniami (prawdopodobnie wyczyścił pamięć podręczną), a punkty przerwania są teraz uruchamiane.

Do Twojej wiadomości Modelowałem swój kod stąd: https://github.com/microsoftgraph/aspnet-connect-sample

Po przekonwertowaniu biblioteki klas na projekt aplikacji sieciowej wpadłem na to i uparłem się. Okazało się, że w moim .csProjpliku miałem to:

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

• w ten sposób budowanie różnych bibliotek dll w podfolderze folderu bin (który ifc. nie będzie działał). Rozwiązaniem była zmiana obu treści tekstowych na OutputPathjust bin\.

Dla mnie to dlatego, że nie są w tej samej przestrzeni nazw. Po usunięciu mojego AppStart z „project.Startup.AppStart” i pozwoleniu im zarówno Startup.cs, jak i Startup.Auth.cs z przestrzenią nazw „project.Startup” wszystko wróciło do normy.

Mam nadzieję, że to pomoże!

Jeśli widzisz ten problem z hostingiem IIS, ale nie podczas debugowania F5, spróbuj utworzyć nową aplikację w IIS.

Naprawiłem to dla mnie. (Windows 10) Ostatecznie usunąłem „złą” aplikację IIS i odtworzyłem identyczną o tej samej nazwie.

Myślę, że niektórzy ludzie próbowali dostać się wyżej, jeśli chcesz programowo sprawić, by Twój serwer OWIN „ożył”, nazwałbyś coś takiego:

using Microsoft.Owin.Hosting;

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

Gdy wykonasz to wywołanie, zobaczysz wywołanie StartupMethod () w debuggerze

Uważam, że następujący artykuł jest bardzo pomocny:

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

W moim przypadku musiałem ustawić następujące opcje, aby uwierzytelnianie Owin działało zamiast uwierzytelniania systemu Windows:

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

To działało dla mnie:

dodaj tryb uwierzytelniania = „Brak”

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

Najpierw dodaj OWIN Auth Class, a następnie włącz OWIN: AutomaticAppStartup w pliku web.config, takim jak Teraz będzie strzelać