web-dev-qa-db-fra.com

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

Supposons, par exemple, dans une toute nouvelle application ASP.NET MVC 5 créée à partir du modèle MVC avec comptes individuels, si je supprime la classe Global.asax.cs et déplace son code de configuration vers Startup.csConfiguration() 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);
    }
}

Pour moi, le fait positif est que, lors de la mise à niveau d'applications ASP.NET 4 vers ASP.NET 5 et de l'utilisation d'éléments qui doivent maintenant être configurés dans la classe Startup.cs, je ne fais pas d'injection de dépendance ni d'autres configurations dans deux classes différentes qui semblent liées. au démarrage et à la configuration.

c#asp.netasp.net-mvcasp.net-mvc-5owin
184
user681768

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 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 telles que Session_Start et Application_Error.
  3. Correction 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, il cessera silencieusement d'appeler Startup.Configuration, ce qui pourrait être difficile à comprendre.

Je pense que la troisième raison est la raison la plus importante pour laquelle nous n’avons pas adopté cette approche par défaut, car certains scénarios n’incluent pas cette DLL et il est agréable de pouvoir modifier les méthodes d’authentification sans invalider l’emplacement où du code non lié enregistrement de la route) est placé.

Mais si aucune de ces raisons ne s’applique dans votre scénario, je pense que vous iriez bien avec cette approche.

161
dmatson

Pour ceux qui recherchent la totalité des étapes: Si vous souhaitez créer une API Web hébergée basée sur IIS et basée sur OWIN, ces étapes devraient vous y aider:

  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 avec le bouton droit de la souris et ajoutez Project -> Web -> ASP.NET Web Application (ciblant .NET 4.6).

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

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

    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'attribut RoutePrefix et la méthode d'action avec Route + HttpGet/PutPost (représentant le verbe HTTP que vous êtes après) et vous devriez être prêt à partir

28
Sudhanshu Mishra

C’est ce que je comprends de la façon dont le lancement/l’hébergement d’une application Web a évolué, car il est très compliqué à suivre. Un petit résumé:

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

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

3. ASP.NET Core: Configurez l'hôte et le serveur Web pour qu'ils utilisent et écrivent le code de votre application. N'est plus obligatoire d'utiliser un serveur Web .NET si vous ciblez .NET Core au lieu de l'intégralité du .NET Framework.

Maintenant, je vais aller un peu plus en détail sur comment cela fonctionne et quelles classes sont utilisées pour démarrer l'application:

ASP.NET classique

Les applications ASP.NET classiques ont le fichier 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 (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 réécriture d’URL dans l’événement Application_Start de votre Global.asax fichier ou utilisez la nouvelle section <system.webserver> de votre fichier web.config.

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 eux-mêmes ont une implémentation d'OWIN appelée projet Katana (distribuée via plusieurs packages NuGet). Cette implémentation fournit l'interface IAppBuilder que vous rencontrez dans une classe Startup et certains composants de middleware OWIN (OMC) fournis par Microsoft. En utilisant IAppBuilder, vous composez un middleware plug-and-play pour créer le pipeline du serveur Web (en plus du pipeline ASP.NET dans IIS7 + comme indiqué ci-dessus) au lieu d'être lié au IIS pipeline (mais vous utilisez maintenant un composant middleware pour CORS, un composant middleware pour l'authentification ...). De ce fait, 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 permet d’héberger votre application OWIN dans IIS7 + en mode intégré, en abonnant votre middleware aux événements de durée de vie appropriés en interne.

La chose qui rend tout si déroutant est que Global.asax est toujours supporté avec la classe OWIN Startup, alors qu'ils peuvent faire les mêmes choses. Par exemple, vous pouvez implémenter CORS dans Global.asax et l'authentification à l'aide du middleware OWIN qui devient vraiment déroutant.

Ma règle d'or est de supprimer le fichier Global.asax en faveur de l'utilisation de Startup chaque fois que je dois ajouter OWIN.

ASP.NET Core

ASP.NET Core est la prochaine évolution et vous pouvez désormais cibler soit le .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 le standard .NET. Cela signifie que vous n'êtes plus limité à un serveur Web .NET (comme dans le point précédent), mais 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 le fichier Program.cs. Là, vous configurez votre hôte et spécifiez à nouveau votre classe Startup dans laquelle vous configurez votre pipeline. L'utilisation de OWIN (à l'aide de la méthode d'extension IAppBuilder.UseOwin) est facultative, mais entièrement prise en charge .

10
Alexander Derck