Czy w ogóle potrzebuję pliku Global.asax.cs, jeśli używam klasy OWIN Startup.cs i przenoszę tam całą konfigurację?

Powiedzmy na przykład, że w zupełnie nowej aplikacji ASP.NET MVC 5 wykonanej z szablonu MVC z indywidualnymi kontami, jeśli usunę Global.asax.csklasę i przeniosę jej kod konfiguracyjny do Startup.cs Configuration()metody w następujący sposób, jakie są wady?

public partial class Startup
{
     public void Configuration(IAppBuilder app)
     {
        AreaRegistration.RegisterAllAreas();
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);

        ConfigureAuth(app);
    }
}

Zaletą dla mnie jest to, że podczas aktualizacji aplikacji ASP.NET 4 do ASP.NET 5 i używania elementów, które teraz muszą być skonfigurowane w klasie Startup.cs, nie robię wstrzykiwania zależności i innej konfiguracji w dwóch różnych klasach, które wydają się powiązane do uruchomienia i konfiguracji.

Startup.Configuracja jest wywoływana nieco później niż Application_Start, ale nie sądzę, że różnica w większości przypadków będzie miała znaczenie.

Uważam, że główne powody, dla których trzymaliśmy drugi kod w Global.asax to:

1. Spójność z poprzednimi wersjami MVC. (To jest miejsce, gdzie wszyscy obecnie oczekują znaleźć ten kod.)
2. Możliwość dodania innych procedur obsługi zdarzeń. W Global.asax możesz obsługiwać inne metody, takie jak Session_Start i Application_Error.
3. Poprawność w różnych scenariuszach uwierzytelniania. Metoda Startup.Configuration jest wywoływana tylko wtedy, gdy w katalogu bin znajduje się Microsoft.Owin.Host.SystemWeb.dll. Jeśli usuniesz tę bibliotekę DLL, po cichu przestanie wywoływać konfigurację startową, co może być trudne do zrozumienia.

Myślę, że trzeci powód jest najważniejszy, ponieważ domyślnie nie przyjęliśmy tego podejścia, ponieważ niektóre scenariusze nie obejmują posiadania tej biblioteki DLL i miło jest móc zmieniać metody uwierzytelniania bez unieważniania lokalizacji, w której niepowiązany kod (np. rejestracja trasy).

Ale jeśli żaden z tych powodów nie ma zastosowania w twoim scenariuszu, myślę, że przydałoby Ci się to podejście.

Dla tych, którzy szukają kompletnych kroków: jeśli chcesz utworzyć oparty na OWIN, internetowy interfejs API hostowany przez IIS, te kroki powinny Cię tam zapewnić:

1. File -> New -> Project
2. W dialogu Installed -> templates -> Other Project types -> Visual Studio Solutions -> Blank Solution targeting .NET 4.6

3. W rozwiązaniu kliknij prawym przyciskiem myszy, dodaj Project -> Web -> ASP.NET Web Application(celowanie .NET 4.6)

   3.1 Teraz W szablonach ASP.NET 4.5 wybierz Pusty jako szablon

   3.2 To tworzy puste rozwiązanie z dwoma pakietami nuget:

   Microsoft.CodeDom.Providers.DotNetCompilerPlatform v 1.0.0
   Microsoft.Net.Compilers v 1.0.0

4. Zainstaluj następujące pakiety:

   Install-Package Microsoft.AspNet.WebApi.WebHost -Version 5.2.3
   Install-Package Microsoft.AspNet.WebApi -Version 5.2.3
   Install-Package WebApiContrib.Formatting.Razor 2.3.0.0

W przypadku OWIN:

Install-Package Microsoft.Owin.Host.SystemWeb 
Install-Package Microsoft.AspNet.WebApi.OwinSelfHost    

Następnie dodaj Startup.cs z metodą konfiguracji:

[assembly:OwinStartup(typeof(namespace.Startup))]
public class Startup
    {
        /// <summary> Configurations the specified application. </summary>
        /// <param name="app">The application.</param>
        public static void Configuration(IAppBuilder app)
        {
            var httpConfiguration = CreateHttpConfiguration();

            app
                .UseWebApi(httpConfiguration);
        }

        /// <summary> Creates the HTTP configuration. </summary>
        /// <returns> An <see cref="HttpConfiguration"/> to bootstrap the hosted API </returns>
        public static HttpConfiguration CreateHttpConfiguration()
        {
            var httpConfiguration = new HttpConfiguration();
            httpConfiguration.MapHttpAttributeRoutes();

            return httpConfiguration;
        }
}

Teraz dodaj klasę, która dziedziczy ApiController, opatrz ją adnotacją RoutePrefixi metodą akcji Route + HttpGet/PutPost(reprezentującą czasownik HTTP, którego szukasz) i powinieneś już iść

Rozumiem, jak ewoluowało uruchamianie / hosting aplikacji WWW, ponieważ jest to dość mylące. Małe podsumowanie:

1. Klasyczny program ASP.NET: Napisz tylko kod aplikacji, aby uruchomić go w ostatnim kroku obowiązkowego potoku IIS

2. ASP.NET z OWIN: Skonfiguruj serwer .NET i napisz kod aplikacji. Nie jest już bezpośrednio sprzężony z IIS, więc nie musisz już go używać.

3. ASP.NET Core: Skonfiguruj hosta i serwer WWW do używania i pisania kodu aplikacji. Nie jest już obowiązkowe korzystanie z serwera .NET, jeśli celem jest .NET Core zamiast pełnego .NET Framework.

Teraz zajmę się bardziej szczegółowo tym, jak to działa i jakie klasy są używane do uruchomienia aplikacji:

Klasyczny ASP.NET

Klasyczne aplikacje ASP.NET mają Global.asaxplik jako punkt wejścia. Te aplikacje mogą być uruchamiane tylko w IIS, a Twój kod jest wykonywany na końcu potoku IIS (więc IIS jest odpowiedzialny za CORS, uwierzytelnianie ... zanim Twój kod się uruchomi). Od IIS 7 możesz uruchomić aplikację w trybie zintegrowanym, który integruje środowisko wykonawcze ASP.NET z IIS. Umożliwia to Twojemu kodowi skonfigurowanie funkcji, które wcześniej nie były możliwe (lub tylko w samych IIS), takich jak przepisywanieApplication_Start adresów URL w przypadku Global.asaxpliku lub użycie nowej <system.webserver>sekcji w web.configpliku.

ASP.NET z OWIN

Przede wszystkim OWIN nie jest biblioteką, ale specyfikacją interakcji serwerów .NET (na przykład IIS) z aplikacjami internetowymi. Same Microsoft mają implementację OWIN o nazwie projekt Katana (dystrybuowanej przez kilka różnych pakietów NuGet). Ta implementacja zapewnia IAppBuilderinterfejs napotkany w Startupklasie oraz niektóre komponenty oprogramowania pośredniego OWIN (OMC) dostarczone przez Microsoft. Za pomocąIAppBuilderzasadniczo tworzysz oprogramowanie pośrednie w trybie plug-and-play, aby utworzyć potok dla serwera WWW (oprócz tylko potoku ASP.NET w IIS7 + jak w powyższym punkcie) zamiast być powiązanym z potokiem IIS (ale teraz używasz komponent oprogramowania pośredniego dla CORS, komponent oprogramowania pośredniego do uwierzytelniania ...). Z tego powodu twoja aplikacja nie jest już specjalnie sprzężona z IIS i możesz ją uruchomić na dowolnym serwerze .NET Webserver, na przykład:

• OwinHost Pakiet może być wykorzystywany do samodzielnego hosta aplikacji z serwera WWW Katana.
• Microsoft.Owin.Host.SystemWeb pakiet jest używany do obsługi aplikacji OWIN w IIS7 + w trybie zintegrowanym, subskrybując swoją middleware do właściwych wydarzeń życiowych wewnętrznie.

To, co sprawia, że ​​wszystko jest tak mylące, to to, że Global.asaxnadal jest obsługiwane wraz z Startupklasą OWIN , podczas gdy oboje mogą robić podobne rzeczy. Na przykład możesz zaimplementować CORS Global.asaxi uwierzytelnianie przy użyciu oprogramowania pośredniego OWIN, co staje się naprawdę mylące.

Moją ogólną zasadą jest całkowite usunięcie Global.asaxpliku na korzyść korzystania za Startupkażdym razem, gdy muszę dodać OWIN.

ASP.NET Core

ASP.NET Core to kolejna ewolucja, teraz możesz kierować reklamy na platformę .NET Core lub pełną platformę .NET Framework. Gdy celujesz w .NET Core, możesz uruchomić aplikację na dowolnym hoście, który obsługuje .NET Standard. Oznacza to, że nie jesteś już ograniczony do serwera .NET (jak w poprzednim punkcie), ale możesz hostować swoją aplikację w kontenerach Docker, serwerze linux, IIS ...

Punktem wejścia dla aplikacji sieci web ASP.NET Core jest Program.csplik. Tam konfigurujesz hosta i ponownie określasz Startupklasę, w której konfigurujesz potok. Korzystanie z OWIN (przy użyciu IAppBuilder.UseOwinmetody rozszerzenia) jest opcjonalne, ale w pełni obsługiwane .