Ho bisogno di un file Global.asax.cs se sto usando una classe OWIN Startup.cs e trasferisco lì tutta la configurazione?

Diciamo ad esempio in una nuovissima applicazione ASP.NET MVC 5 creata dal modello MVC con account individuali, se elimino la Global.asax.csclasse e sposto il suo codice di configurazione sul Startup.cs Configuration()metodo come segue, quali sono gli svantaggi?

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

L'aspetto positivo per me è che quando aggiorno le applicazioni ASP.NET 4 ad ASP.NET 5 e usando pezzi che ora devono essere configurati nella classe Startup.cs, non sto facendo l'iniezione di dipendenza e altre configurazioni in due diverse classi che sembrano correlate all'avvio e alla configurazione.

Startup.Configuration viene chiamato leggermente più tardi di Application_Start, ma non penso che la differenza avrà molta importanza nella maggior parte dei casi.

Credo che i motivi principali per cui abbiamo mantenuto l'altro codice in Global.asax siano:

1. Coerenza con le versioni precedenti di MVC. (Ecco dove tutti si aspettano attualmente di trovare questo codice.)
2. Possibilità di aggiungere altri gestori di eventi. In Global.asax, puoi gestire altri metodi come Session_Start e Application_Error.
3. Correttezza in una varietà di scenari di autenticazione. Il metodo Startup.Configuration viene chiamato solo se si dispone di Microsoft.Owin.Host.SystemWeb.dll nella directory bin. Se rimuovi questa DLL, smetterà silenziosamente di chiamare Startup.Configuration, che potrebbe essere difficile da capire.

Penso che il terzo motivo sia il più importante che non abbiamo adottato questo approccio per impostazione predefinita, poiché alcuni scenari non includono avere questa DLL ed è bello poter cambiare gli approcci di autenticazione senza invalidare la posizione in cui il codice non correlato (come registrazione del percorso).

Ma se nessuna di queste ragioni si applica al tuo scenario, penso che staresti bene usando questo approccio.

Per coloro che cercano i passaggi completi: se stai cercando di creare un'API Web ospitata su IW basata su OWIN, questi passaggi dovrebbero portarti lì:

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

3. Sulla soluzione, fare clic con il tasto destro del mouse, aggiungere Project -> Web -> ASP.NET Web Application(targeting .NET 4.6)

   3.1 Ora Nei modelli ASP.NET 4.5, selezionare Vuoto come modello

   3.2 Questo crea una soluzione vuota con due pacchetti nuget:

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

4. Installa i seguenti pacchetti:

   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
   

Per OWIN:

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

Quindi aggiungere Startup.cs con il metodo di configurazione:

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

Ora aggiungi una classe che eredita ApiController, annotala con l' RoutePrefixattributo e il metodo di azione con Route + HttpGet/PutPost(che rappresenta il verbo Http che stai cercando) e dovresti essere pronto per andare

Questa è la mia comprensione di come si è evoluto l'avvio / l'hosting di un'applicazione Web in quanto è abbastanza confuso da seguire. Un piccolo riassunto:

1. ASP.NET classico: scrivere solo il codice dell'applicazione da eseguire nell'ultimo passaggio della pipeline IIS obbligatoria

2. ASP.NET con OWIN: configura un server web .NET e scrivi il codice dell'applicazione. Non è più direttamente associato a IIS, quindi non sei più costretto a usarlo.

3. ASP.NET Core: configura sia l'host che il server web per utilizzare e scrivere il codice dell'applicazione. Non è più obbligatorio utilizzare un server Web .NET se si sceglie come destinazione .NET Core anziché .NET Framework completo.

Ora andrò un po 'più in dettaglio su come funziona e quali classi vengono utilizzate per avviare l'applicazione:

ASP.NET classico

Le applicazioni ASP.NET classiche hanno il Global.asaxfile come punto di ingresso. Queste applicazioni possono essere eseguite solo in IIS e il codice viene eseguito alla fine della pipeline IIS (quindi IIS è responsabile per CORS, autenticazione ... prima ancora che il codice venga eseguito). Da IIS 7 è possibile eseguire l'applicazione in modalità integrata che integra il runtime ASP.NET in IIS. Ciò consente al codice di configurare funzionalità che prima non era possibile (o solo in IIS stesso) come la riscrittura degli URL in Application_Startcaso di Global.asaxfile o di utilizzare la nuova <system.webserver>sezione del web.configfile.

ASP.NET con OWIN

Innanzitutto OWIN non è una libreria ma una specifica di come i server Web .NET (ad esempio IIS) interagiscono con le applicazioni Web. Microsoft stessa ha un'implementazione di OWIN chiamata project Katana (distribuita attraverso diversi pacchetti NuGet). Questa implementazione fornisce l' IAppBuilderinterfaccia che incontri in una Startupclasse e alcuni componenti middleware OWIN (OMC) forniti da Microsoft. utilizzandoIAppBuilderfondamentalmente componi il middleware in un modo plug-and-play per creare la pipeline per il server web (oltre alla sola pipeline ASP.NET in IIS7 + come nel punto sopra) invece di essere legata alla pipeline IIS (ma ora usi un componente middleware per CORS, un componente middleware per l'autenticazione ...). Per questo motivo, l'applicazione non è più specificamente associata a IIS ed è possibile eseguirla su qualsiasi server Web .NET, ad esempio:

• Il pacchetto OwinHost può essere utilizzato per ospitare autonomamente l'applicazione con un server web Katana.
• Il pacchetto Microsoft.Owin.Host.SystemWeb viene utilizzato per ospitare l'applicazione OWIN in IIS7 + in modalità integrata, sottoscrivendo il middleware per gli eventi di durata corretti internamente.

La cosa che rende tutto così confuso è che Global.asaxè ancora supportato insieme alla Startupclasse OWIN , mentre entrambi possono fare cose simili. Ad esempio, è possibile implementare CORS in Global.asaxe autenticazione utilizzando il middleware OWIN che diventa davvero confuso.

La mia regola pratica è quella di rimuovere il Global.asaxfile completamente a favore dell'uso Startupogni volta che devo aggiungere OWIN.

ASP.NET Core

ASP.NET Core è la prossima evoluzione e ora puoi scegliere come target .NET Core o .NET Framework completo. Quando si utilizza .NET Core, è possibile eseguire l'applicazione su qualsiasi host che supporti .NET Standard. Questo significa che non sei più limitato a un server web .NET (come nel punto precedente), ma puoi ospitare la tua applicazione in contenitori Docker, un server web Linux, IIS ...

Il punto di ingresso per un'applicazione Web ASP.NET Core è il Program.csfile. Lì si configura l'host e si specifica nuovamente la Startupclasse in cui si configura la pipeline. L'uso di OWIN (usando il IAppBuilder.UseOwinmetodo di estensione) è facoltativo, ma completamente supportato .