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?

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.

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.

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

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 .