Ai-je besoin d'un fichier Global.asax.cs du tout si j'utilise une classe OWIN Startup.cs et y déplace toute la configuration?

197

Disons par exemple dans une toute nouvelle application ASP.NET MVC 5 faite à partir du modèle MVC avec des comptes individuels, si je supprime la Global.asax.csclasse et déplace son code de configuration vers la Startup.cs Configuration()méthode comme suit, quels sont les inconvénients?

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'inconvénient pour moi est que lors de la mise à niveau des applications ASP.NET 4 vers ASP.NET 5 et en utilisant des éléments qui doivent maintenant être configurés dans la classe Startup.cs, je ne fais pas d'injection de dépendance et d'autres configurations dans deux classes différentes qui semblent liées au démarrage et à la configuration.

iliketocode
la source
AreaRegistration.RegisterAllAreas();Causé une erreur pour moi car cette méthode ne peut pas être utilisée lors du démarrage comme celui-ci, uniquement dans Application_Start. Cependant, mon application est une API et cette méthode n'est apparemment utile que pour les applications MVC: stackoverflow.com/questions/18404637/…
Harvey

Réponses:

171

Startup.Configuration est appelé un peu plus tard que Application_Start, mais je ne pense pas que la différence importera beaucoup dans la plupart des cas.

Je crois que les principales raisons pour lesquelles nous avons conservé l'autre code dans Global.asax sont:

  1. Cohérence avec les versions précédentes de MVC. (C'est là que tout le monde s'attend actuellement à trouver ce code.)
  2. Possibilité d'ajouter d'autres gestionnaires d'événements. Dans Global.asax, vous pouvez gérer d'autres méthodes telles que Session_Start et Application_Error.
  3. Exactitude dans divers scénarios d'authentification. La méthode Startup.Configuration n'est appelée que si vous avez Microsoft.Owin.Host.SystemWeb.dll dans votre répertoire bin. Si vous supprimez cette DLL, elle cessera silencieusement d'appeler Startup.Configuration, ce qui pourrait être difficile à comprendre.

Je pense que la troisième raison est la plus importante, nous n'avons pas adopté cette approche par défaut, car certains scénarios n'incluent pas d'avoir cette DLL, et il est agréable de pouvoir changer les approches d'authentification sans invalider l'emplacement où le code non lié (comme enregistrement de l'itinéraire) est placé.

Mais si aucune de ces raisons ne s'applique à votre scénario, je pense que vous seriez d'accord avec cette approche.

dmatson
la source
19
Un autre avantage de l'utilisation de Startup.Configuration () est que vous pouvez facilement héberger votre site Web en utilisant l'auto-hôte owin avec seulement 1 ligne de code: WebApp.Start <Startup> (" localhost: 3001 /" ) asp.net/web-api/ aperçu / hébergement-aspnet-web-api /… C'est particulièrement pratique pour écrire des tests d'intégration
Boris Lipschitz
16
Afin d'éviter l'effet secondaire «Arrêtez silencieusement d'appeler Startup.Configuration», vous pouvez ajouter une clé web.config appSettings «owin: appStartup» qui spécifie explicitement le type à utiliser pour le démarrage OWIN, au lieu de s'appuyer sur la convention de nom Chercher. Ceci est également pratique pour prendre en charge différentes configurations pour différents environnements (dev / test / prod)
Thiago Silva
2
+1 pour # 3. Je voulais un démarrage WebApi.Owinsimplifié d'une API Web, j'ai donc créé un modèle de site Web ASP.NET vide et ajouté un package nuget. Je m'attendais à tort à ce que la dépendance inclue tout pour s'exécuter sur IIS. Je ne sais pas pourquoi je pensais cela, car je voulais un démarrage Owin pour découpler la dépendance IIS en premier lieu.
Pluc
@dmatson Avec votre dernière déclaration, vous sous-entendez que la classe de démarrage est uniquement destinée à l'authentification?
Sam
@Sam, aucun démarrage n'est également utilisé pour d'autres configurations, telles que les filtres et les itinéraires, comme le montre la question.
dmatson
33

Pour ceux qui recherchent les étapes complètes: Si vous cherchez à créer une API Web hébergée basée sur OWIN et IIS, ces étapes devraient vous y mener:

  1. File -> New -> Project
  2. Dans le dialogue, Installed -> templates -> Other Project types -> Visual Studio Solutions -> Blank Solution targeting .NET 4.6
  3. Sur la solution, faites un clic droit, ajoutez Project -> Web -> ASP.NET Web Application(ciblage .NET 4.6)

    3.1 Maintenant, dans les modèles ASP.NET 4.5, choisissez Vide comme modèle

    3.2 Cela crée une solution vierge avec deux packages de pépites:

    Microsoft.CodeDom.Providers.DotNetCompilerPlatform v 1.0.0
    Microsoft.Net.Compilers v 1.0.0
  4. Installez les packages suivants:

    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

Pour OWIN:

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

Ajoutez ensuite Startup.cs avec la méthode de configuration:

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

Maintenant, ajoutez une classe qui hérite de ApiController, annotez-la avec l' RoutePrefixattribut et la méthode d'action avec Route + HttpGet/PutPost(représentant le verbe Http que vous recherchez) et vous devriez être prêt à partir

Sudhanshu Mishra
la source
1
Merci @dotnetguy !!! J'ai essayé de me débarrasser complètement de Global.asax mais je n'ai pas pu. Enfin en suivant vos pas, ça a marché pour moi. La partie manquante dans mon cas était la référence à Install-Package Microsoft.AspNet.WebApi.OwinSelfHostUne fois que j'ajoute cela à mon api, j'ai pu supprimer le global.asax.
yyardim
2
@yyardim Je pense que le OwinSelfHost n'a pas grand-chose à voir avec le fichier global.asax, il vous donne seulement la possibilité d'héberger votre application en dehors d'iis, dans un service Windows par exemple
Alexander Derck
@dotnetguy Install-Package WebApiContrib.Formatting.Razor 2.3.0.0affiche une erreur de package d'installation introuvable. Vous avez installé l'installation de ce paquet avec Install-Package WebApiContrib.Formatting.Razor 2.3.0, donc sans le dernier.0
Dairo
1
@dotnetguy La [assembly:OwinStartup(typeof(namespace.Startup))]partie doit être au-dessus de la partie de l'espace de noms sinon cela donne l'erreur suivanteAssembly and module attributes must precede all other elements defined in a file except using clauses and extern alias declarations.
Dairo
16

C'est ma compréhension de la façon dont le démarrage / l'hébergement d'une application Web a évolué, car c'est assez déroutant à suivre. Un petit résumé:

1. ASP.NET classique: n'écrivez que le code d'application à exécuter à la dernière étape du pipeline IIS obligatoire

2. ASP.NET avec OWIN: configurez un serveur Web .NET et écrivez votre code d'application. N'est plus directement couplé à IIS, vous n'êtes donc plus obligé de l'utiliser.

3. ASP.NET Core: configurez l'hôte et le serveur Web pour utiliser et écrire le code de votre application. Il n'est plus obligatoire d'utiliser un serveur Web .NET si vous ciblez .NET Core au lieu du .NET Framework complet.


Je vais maintenant aller un peu plus en détail sur son fonctionnement et sur les classes utilisées pour démarrer l'application:

ASP.NET classique

Les applications ASP.NET classiques ont le Global.asaxfichier comme point d'entrée. Ces applications ne peuvent être exécutées que dans IIS et votre code est exécuté à la fin du pipeline IIS (donc IIS est responsable de CORS, de l'authentification ... avant même que votre code ne s'exécute). Depuis IIS 7, vous pouvez exécuter votre application en mode intégré qui intègre le runtime ASP.NET dans IIS. Cela permet à votre code de configurer des fonctionnalités qui n'étaient pas possibles auparavant (ou uniquement dans IIS lui-même) telles que la réécriture d'URL en Application_Startcas de votre Global.asaxfichier ou d'utiliser la nouvelle <system.webserver>section de votre web.configfichier.

ASP.NET avec OWIN

Tout d'abord, OWIN n'est pas une bibliothèque mais une spécification de la façon dont les serveurs Web .NET (par exemple IIS) interagissent avec les applications Web. Microsoft a lui-même une implémentation de OWIN appelée projet Katana (distribuée via plusieurs packages NuGet différents). Cette implémentation fournit leIAppBuilder interface que vous rencontrez dans un queStartup classe et certains composants middleware OWIN (OMC) fournis par Microsoft. En utilisantIAppBuildervous composez essentiellement un middleware de manière plug-and-play pour créer le pipeline pour le serveur Web (en plus uniquement du pipeline ASP.NET dans IIS7 + comme dans le point ci-dessus) au lieu d'être lié au pipeline IIS (mais maintenant vous utilisez un composant middleware pour CORS, un composant middleware pour l'authentification ...). Pour cette raison, votre application n'est plus spécifiquement couplée à IIS et vous pouvez l'exécuter sur n'importe quel serveur Web .NET, par exemple:

  • Le package OwinHost peut être utilisé pour auto-héberger votre application avec un serveur Web Katana.
  • Le package Microsoft.Owin.Host.SystemWeb est utilisé pour héberger votre application OWIN dans IIS7 + en mode intégré, en abonnant votre middleware aux événements de durée de vie corrects en interne.

Ce qui rend tout si confus, c'est qu'il Global.asaxest toujours pris en charge avec la Startupclasse OWIN , alors qu'ils peuvent tous deux faire des choses similaires. Par exemple, vous pouvez implémenter Global.asaxCORS et l'authentification à l'aide du middleware OWIN, ce qui devient vraiment déroutant.

Ma règle de base est de supprimer le Global.asaxfichier au total en faveur de l'utilisation Startupchaque fois que j'ai besoin d'ajouter OWIN.

ASP.NET Core

ASP.NET Core est la prochaine évolution et vous pouvez désormais cibler soit .NET Core soit le .NET Framework complet. Lorsque vous ciblez .NET Core, vous pouvez exécuter votre application sur n'importe quel hôte prenant en charge la norme .NET. Cela signifie que vous n'êtes plus limité à un serveur Web .NET (comme au point précédent), mais pouvez héberger votre application dans des conteneurs Docker, un serveur Web Linux, IIS ...

Le point d'entrée pour une application Web ASP.NET Core est le Program.csfichier. Là, vous configurez votre hôte et spécifiez à nouveau votre Startupclasse où vous configurez votre pipeline. L'utilisation d'OWIN (en utilisant la IAppBuilder.UseOwinméthode d'extension) est facultative, mais entièrement prise en charge .

Alexander Derck
la source