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

Question

Disons par exemple que dans une toute nouvelle application ASP.NET MVC 5 créée à partir du modèle MVC avec comptes individuels, si je supprime l'élément Global.asax.cs et déplacer son code de configuration vers 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'avantage pour moi est que lorsque je mets à niveau des applications ASP.NET 4 vers ASP.NET 5 et que j'utilise des éléments qui doivent maintenant être configurés dans la classe Startup.cs, je ne fais pas d'injection de dépendances et d'autres configurations dans deux classes différentes qui semblent liées au démarrage et à la configuration.

Answer 1

Startup.Configuration est appelé légèrement plus tard que Application_Start, mais je ne pense pas que la différence soit importante dans la plupart des cas.

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

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 comme Session_Start et Application_Error.
3. L'exactitude dans une variété de 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 la présence de cette DLL, et il est agréable de pouvoir changer d'approche d'authentification sans invalider l'emplacement où est placé le code non lié (comme l'enregistrement des routes).

Mais si aucune de ces raisons ne s'applique à votre scénario, je pense que cette approche vous conviendra parfaitement.

Answer 2

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

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, cliquez à droite, ajoutez Project -> Web -> ASP.NET Web Application (visant .NET 4.6)

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

   3.2 Cela crée une solution vierge avec deux paquets nuget :

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

4. Installez les paquets 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    

Puis ajoutez 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 et l'annoter avec RoutePrefix et la méthode d'action avec l'attribut Route + HttpGet/PutPost (représentant le verbe Http que vous recherchez) et vous devriez être prêt à partir.

Answer 3

C'est ainsi que j'ai compris l'évolution du démarrage et de l'hébergement d'une application web, car tout cela est assez confus à suivre. Un petit résumé :

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

2. ASP.NET avec OWIN : Configurez un serveur Web .NET et écrivez le code de votre 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 à utiliser et écrivez 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 vous expliquer un peu plus en détail comment cela fonctionne et quelles classes sont utilisées pour démarrer l'application :

ASP.NET classique

Les applications ASP.NET classiques ont le Global.asax 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 (IIS est donc responsable de CORS, de l'authentification... avant même l'exécution de votre code). 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 seulement dans IIS lui-même) telles que réécriture de l'URL dans le Application_Start l'événement de votre Global.asax ou utiliser le nouveau fichier <system.webserver> dans votre web.config fichier.

ASP.NET avec OWIN

Tout d'abord OWIN n'est pas une bibliothèque mais une spécification de la manière dont les serveurs web .NET (par exemple IIS) interagissent avec les applications web. Microsoft dispose elle-même d'une implémentation d'OWIN appelée projet Katana (distribué par plusieurs paquets NuGet différents). Cette implémentation fournit le IAppBuilder que vous rencontrez dans une Startup et certains composants middleware OWIN (OMC) fournis par Microsoft. Utilisation de IAppBuilder vous composez essentiellement un middleware de manière plug-and-play pour créer le pipeline du serveur Web (en plus 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...). De ce fait, votre application n'est plus spécifiquement liée à IIS et vous pouvez l'exécuter sur n'importe quel serveur Web .NET, par exemple :

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

La chose qui rend tout si confus est que Global.asax est toujours pris en charge avec le système OWIN Startup alors qu'ils peuvent tous deux faire des choses similaires. Par exemple, vous pouvez implémenter CORS dans Global.asax et l'authentification en utilisant le middleware OWIN qui devient vraiment déroutant.

Ma règle d'or est d'enlever le Global.asax en faveur de l'utilisation du fichier Startup chaque 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 tout hôte prenant en charge la norme .NET. Cela signifie que vous n'êtes plus limité à un serveur Web .NET (comme dans le point précédent), mais que vous pouvez héberger votre application dans des conteneurs Docker, un serveur Web Linux, IIS...

Le point d'entrée d'une application web ASP.NET Core est l'élément Program.cs fichier. Là, vous configurez votre hôte et vous spécifiez à nouveau votre Startup où vous configurez votre pipeline. En utilisant OWIN (en utilisant le IAppBuilder.UseOwin ) est facultative, mais entièrement soutenu .