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


197

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.


AreaRegistration.RegisterAllAreas();Ho causato un errore per me in quanto questo metodo non può essere utilizzato durante l'avvio in questo modo, solo in Application_Start. Tuttavia, la mia applicazione è un'API e questo metodo è apparentemente utile solo per le applicazioni MVC: stackoverflow.com/questions/18404637/…
Harvey,

Risposte:


171

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.


19
Un altro vantaggio dell'utilizzo di Startup.Configuration () è che puoi facilmente ospitare il tuo sito Web utilizzando owin self-host con solo 1 riga di codice: WebApp.Start <Startup> (" localhost: 3001 /" ) asp.net/web-api/ panoramica / hosting-aspnet-web-api / ... È particolarmente utile per scrivere test di integrazione
Boris Lipschitz,

16
Per evitare l'effetto collaterale "smetti silenziosamente di chiamare Startup.Configuration", puoi aggiungere una chiave web.config appSettings "owin: appStartup" che specifica esplicitamente il tipo da utilizzare per l'avvio OWIN, invece di fare affidamento sulla convenzione dei nomi consultare. Questo è utile anche per supportare diverse configurazioni per ambienti diversi (sviluppo / test / prod)
Thiago Silva,

2
+1 per # 3. Volevo un inizio semplice per un'API Web, quindi ho creato un sito Web ASP.NET modello vuoto e aggiunto WebApi.Owinun pacchetto nuget. Mi aspettavo erroneamente che la dipendenza includesse tutto per essere eseguito su IIS. Non ho idea del motivo per cui ho pensato che da quando volevo che una startup Owin avesse disaccoppiato la dipendenza IIS in primo luogo.
Pluc

@dmatson Con la tua ultima affermazione insinui fondamentalmente che la classe Startup è destinata esclusivamente all'autenticazione?
Sam,

@Sam, nessun avvio viene utilizzato anche per altre configurazioni, come filtri e route, come mostra la domanda.
dmatson,

33

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


1
Grazie @dotnetguy !!! Ho cercato di sbarazzarmi di Global.asax ma non ci sono riuscito. Finalmente seguendo i tuoi passi, ha funzionato per me. La parte mancante nel mio caso era il riferimento a Install-Package Microsoft.AspNet.WebApi.OwinSelfHostUna volta che l'ho aggiunto alla mia API, sono stato in grado di eliminare global.asax.
yyardim

2
@yyardim Penso che OwinSelfHost non abbia molto a che fare con il file global.asax, ti dà solo la possibilità di ospitare la tua applicazione al di fuori di IIS, ad esempio in un servizio di Windows
Alexander Derck,

@dotnetguy Install-Package WebApiContrib.Formatting.Razor 2.3.0.0mostra un errore del pacchetto di installazione non trovato. L'installazione di questo pacchetto funziona Install-Package WebApiContrib.Formatting.Razor 2.3.0correttamente, quindi senza l'ultimo.0
Dairo,

1
@dotnetguy La [assembly:OwinStartup(typeof(namespace.Startup))]parte deve trovarsi sopra la parte dello spazio dei nomi, altrimenti viene visualizzato il seguente erroreAssembly and module attributes must precede all other elements defined in a file except using clauses and extern alias declarations.
Dairo,

16

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 .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.