Benötige ich überhaupt eine Global.asax.cs-Datei, wenn ich eine OWIN Startup.cs-Klasse verwende und die gesamte Konfiguration dorthin verschiebe?

Angenommen, in einer brandneuen ASP.NET MVC 5-Anwendung, die aus der Vorlage MVC mit Einzelkonten erstellt wurde , sind die Nachteile , wenn ich die Global.asax.csKlasse lösche und ihren Konfigurationscode Startup.cs Configuration()wie folgt in die Methode verschiebe.

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);
    }
}

Das Beste für mich ist, dass ich beim Aktualisieren von ASP.NET 4-Anwendungen auf ASP.NET 5 und beim Verwenden von Teilen, die jetzt in der Startup.cs-Klasse konfiguriert werden müssen, keine Abhängigkeitsinjektion und keine andere Konfiguration in zwei verschiedenen Klassen durchführe, die verwandt zu sein scheinen zum Starten und Konfigurieren.

Startup.Configuration wird etwas später als Application_Start aufgerufen, aber ich denke nicht, dass der Unterschied in den meisten Fällen von großer Bedeutung ist.

Ich glaube, die Hauptgründe, warum wir den anderen Code in Global.asax beibehalten haben, sind:

1. Konsistenz mit früheren Versionen von MVC. (Dort erwartet derzeit jeder, diesen Code zu finden.)
2. Möglichkeit, andere Ereignishandler hinzuzufügen. In Global.asax können Sie andere Methoden wie Session_Start und Application_Error verarbeiten.
3. Korrektheit in verschiedenen Authentifizierungsszenarien. Die Startup.Configuration-Methode wird nur aufgerufen, wenn Sie Microsoft.Owin.Host.SystemWeb.dll in Ihrem bin-Verzeichnis haben. Wenn Sie diese DLL entfernen, wird der Aufruf von Startup.Configuration stillschweigend beendet, was möglicherweise schwer zu verstehen ist.

Ich denke, der dritte Grund ist der wichtigste, den wir nicht standardmäßig gewählt haben, da einige Szenarien diese DLL nicht enthalten, und es ist schön, Authentifizierungsansätze ändern zu können, ohne den Speicherort ungültig zu machen, an dem nicht verwandter Code (wie z Routenregistrierung) wird platziert.

Wenn jedoch keiner dieser Gründe in Ihrem Szenario zutrifft, ist dieser Ansatz meines Erachtens in Ordnung.

Für diejenigen, die nach den vollständigen Schritten suchen: Wenn Sie eine OWIN-basierte, von IIS gehostete Web-API erstellen möchten, sollten diese Schritte Sie dahin führen:

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

3. Klicken Sie mit der rechten Maustaste auf die Lösung und fügen Sie sie hinzu Project -> Web -> ASP.NET Web Application (Targeting von .NET 4.6).

   3.1 Jetzt Wählen Sie in den ASP.NET 4.5-Vorlagen Leere als Vorlage

   3.2 Dadurch wird eine leere Lösung mit zwei Nuget-Paketen erstellt:

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

4. Installieren Sie die folgenden Pakete:

   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

Für OWIN:

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

Fügen Sie dann Startup.cs mit der Konfigurationsmethode hinzu:

[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;
        }
}

Fügen Sie nun eine Klasse hinzu, die von erbt ApiController, kommentieren Sie sie mit dem RoutePrefixAttribut und der Aktionsmethode mit Route + HttpGet/PutPost(die das HTTP-Verb darstellt, nach dem Sie suchen), und Sie sollten bereit sein

Dies ist mein Verständnis davon, wie sich das Starten / Hosten einer Webanwendung entwickelt hat, da es ziemlich verwirrend ist, dem zu folgen. Eine kleine Zusammenfassung:

1. Klassisches ASP.NET: Schreiben Sie nur den Anwendungscode, der im letzten Schritt der obligatorischen IIS-Pipeline ausgeführt werden soll

2. ASP.NET mit OWIN: Konfigurieren Sie einen .NET-Webserver und schreiben Sie Ihren Anwendungscode. Nicht mehr direkt mit IIS verbunden, sodass Sie nicht mehr gezwungen sind, es zu verwenden.

3. ASP.NET Core: Konfigurieren Sie sowohl den Host als auch den Webserver für die Verwendung und das Schreiben Ihres Anwendungscodes. Die Verwendung eines .NET-Webservers ist nicht mehr obligatorisch, wenn Sie auf .NET Core anstelle des vollständigen .NET Frameworks abzielen.

Jetzt werde ich etwas genauer darauf eingehen, wie es funktioniert und welche Klassen zum Starten der Anwendung verwendet werden:

Klassisches ASP.NET

Klassische ASP.NET-Anwendungen haben die Global.asaxDatei als Einstiegspunkt. Diese Anwendungen können nur in IIS ausgeführt werden und Ihr Code wird am Ende der IIS-Pipeline ausgeführt (daher ist IIS für CORS, Authentifizierung ... verantwortlich, bevor Ihr Code überhaupt ausgeführt wird). Seit IIS 7 können Sie Ihre Anwendung im integrierten Modus ausführen, der die ASP.NET-Laufzeit in IIS integriert. Auf diese Weise kann Ihr Code Funktionen konfigurieren, die zuvor (oder nur in IIS selbst) nicht möglich waren, z. B. das UmschreibenApplication_Start von URLs im Falle Ihrer Global.asaxDatei oder den neuen <system.webserver>Abschnitt in Ihrer web.configDatei verwenden.

ASP.NET mit OWIN

Zunächst einmal ist OWIN keine Bibliothek, sondern eine Spezifikation der Interaktion von .NET-Webservern (z. B. IIS) mit Webanwendungen. Microsoft selbst hat eine Implementierung von OWIN namens Project Katana (verteilt über mehrere verschiedene NuGet-Pakete). Diese Implementierung bietet die IAppBuilderSchnittstelle, auf die Sie in einer StartupKlasse stoßen, und einige von Microsoft bereitgestellte OWIN-Middleware-Komponenten (OMC). Verwenden vonIAppBuilder Möglichkeit, Middleware im Plug-and-Play-Verfahren zu erstellen, um die Pipeline für den Webserver zu erstellen (zusätzlich zu nur der ASP.NET-Pipeline in IIS7 + wie oben beschrieben), anstatt an die IIS-Pipeline gebunden zu sein ( Jetzt verwenden Sie jedoch eine Middleware-Komponente für CORS, eine Middleware-Komponente für die Authentifizierung ...). Aus diesem Grund ist Ihre Anwendung nicht mehr speziell an IIS gekoppelt und kann auf jedem .NET-Webserver ausgeführt werden, zum Beispiel:

• Mit dem OwinHost- Paket können Sie Ihre Anwendung mit einem Katana-Webserver selbst hosten.
• Das Microsoft.Owin.Host.SystemWeb- Paket wird verwendet, um Ihre OWIN-Anwendung in IIS7 + im integrierten Modus zu hosten, indem Sie Ihre Middleware intern für die richtigen lebenslangen Ereignisse abonnieren.

Das, was alles so verwirrend macht, ist, dass Global.asaxes immer noch zusammen mit der OWIN- StartupKlasse unterstützt wird, während beide ähnliche Dinge tun können. Zum Beispiel könnten Sie CORS in Global.asaxund Authentifizierung mit OWIN-Middleware implementieren, was sehr verwirrend wird.

Meine Faustregel ist, die Global.asaxDatei insgesamt zu entfernen, um sie zu verwenden, Startupwenn ich OWIN hinzufügen muss.

ASP.NET Core

ASP.NET Core ist die nächste Entwicklung. Jetzt können Sie entweder auf .NET Core oder auf das vollständige .NET Framework abzielen. Wenn Sie auf .NET Core abzielen, können Sie Ihre Anwendung auf jedem Host ausführen, der .NET Standard unterstützt. Dies bedeutet, dass Sie nicht mehr auf einen .NET-Webserver beschränkt sind (wie im vorherigen Punkt), sondern Ihre Anwendung in Docker-Containern, einem Linux-Webserver, IIS ... hosten können.

Der Einstiegspunkt für eine ASP.NET Core-Webanwendung ist die Program.csDatei. Dort konfigurieren Sie Ihren Host und geben erneut Ihre StartupKlasse an, in der Sie Ihre Pipeline konfigurieren. Die Verwendung von OWIN (mithilfe der IAppBuilder.UseOwinErweiterungsmethode) ist optional, wird jedoch vollständig unterstützt .