¿Necesito un archivo Global.asax.cs si estoy usando una clase OWIN Startup.cs y muevo toda la configuración allí?

Digamos, por ejemplo, en una nueva aplicación ASP.NET MVC 5 hecha desde la plantilla MVC con Cuentas Individuales, si elimino la Global.asax.csclase y muevo su código de configuración al Startup.cs Configuration()método de la siguiente manera, ¿cuáles son las desventajas?

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

Lo bueno para mí es que cuando actualizo aplicaciones ASP.NET 4 a ASP.NET 5 y utilizo piezas que ahora deben configurarse en la clase Startup.cs, no estoy haciendo la inyección de dependencia y otras configuraciones en dos clases diferentes que parecen relacionadas a la puesta en marcha, y la configuración.

Startup.Configuration se llama un poco más tarde que Application_Start, pero no creo que la diferencia importe mucho en la mayoría de los casos.

Creo que las principales razones por las que guardamos el otro código en Global.asax son:

1. Consistencia con versiones anteriores de MVC. (Ahí es donde todos esperan encontrar este código actualmente).
2. Posibilidad de agregar otros controladores de eventos. En Global.asax, puede manejar otros métodos como Session_Start y Application_Error.
3. Corrección en una variedad de escenarios de autenticación. El método Startup.Configuration solo se llama si tiene Microsoft.Owin.Host.SystemWeb.dll en su directorio bin. Si elimina esta DLL, dejará de llamar silenciosamente a Startup.Configuration, lo que podría ser difícil de entender.

Creo que la tercera razón es la más importante, no tomamos este enfoque de forma predeterminada, ya que algunos escenarios no incluyen tener esta DLL, y es bueno poder cambiar los enfoques de autenticación sin invalidar la ubicación donde el código no relacionado (como registro de ruta) se coloca.

Pero si ninguna de esas razones se aplica en su escenario, creo que estaría bien con este enfoque.

Para aquellos que buscan los pasos completos: si está buscando crear una API web alojada en IIS basada en OWIN, estos pasos deberían llevarlo hasta allí:

1. File -> New -> Project
2. En el diálogo Installed -> templates -> Other Project types -> Visual Studio Solutions -> Blank Solution targeting .NET 4.6

3. En la solución, haga clic con el botón derecho y agregue Project -> Web -> ASP.NET Web Application(dirigido a .NET 4.6)

   3.1 Ahora, en las plantillas ASP.NET 4.5, elija Vacío como plantilla

   3.2 Esto crea una solución en blanco con dos paquetes nuget:

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

4. Instale los siguientes paquetes:

   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

Para OWIN:

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

Luego agregue Startup.cs con el método de configuración:

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

Ahora agregue una clase que herede ApiController, anótela con el RoutePrefixatributo y el método de acción con Route + HttpGet/PutPost(que representa el verbo Http que está buscando) y debería estar listo para comenzar

Esta es mi comprensión de cómo evolucionó el inicio / alojamiento de una aplicación web, ya que todo es bastante confuso de seguir. Un pequeño resumen:

1. ASP.NET clásico: escriba solo el código de la aplicación que se ejecutará en el último paso de la canalización obligatoria de IIS

2. ASP.NET con OWIN: configure un servidor web .NET y escriba el código de su aplicación. Ya no está directamente acoplado a IIS, por lo que ya no estás obligado a usarlo.

3. ASP.NET Core: configure el host y el servidor web para usar y escribir el código de su aplicación. Ya no es obligatorio usar un servidor web .NET si se dirige a .NET Core en lugar del .NET Framework completo.

Ahora entraré un poco más en detalles sobre cómo funciona y qué clases se utilizan para iniciar la aplicación:

ASP.NET clásico

Las aplicaciones ASP.NET clásicas tienen el Global.asaxarchivo como punto de entrada. Estas aplicaciones solo se pueden ejecutar en IIS y su código se ejecuta al final de la canalización de IIS (por lo que IIS es responsable de CORS, la autenticación ... incluso antes de que se ejecute su código). Desde IIS 7 puede ejecutar su aplicación en modo integrado que integra el tiempo de ejecución ASP.NET en IIS. Esto permite que su código configure la funcionalidad que antes no era posible (o solo en IIS), como la reescritura de URL en el Application_Startcaso de su Global.asaxarchivo o use la nueva <system.webserver>sección en suweb.config archivo.

ASP.NET con OWIN

En primer lugar, OWIN no es una biblioteca, sino una especificación de cómo los servidores web .NET (por ejemplo, IIS) interactúan con las aplicaciones web. Microsoft tiene una implementación de OWIN llamada proyecto Katana (distribuida a través de varios paquetes NuGet diferentes). Esta implementación proporciona la IAppBuilderinterfaz con la que se encuentra básicamente componiendo middleware de una manera plug-and-play para crear la tubería para el servidor web (además de solo la tubería ASP.NET en IIS7 + como en el punto anterior) en lugar de estar vinculado a la tubería de IIS (pero ahora usa un componente de middleware para CORS, un componente de middleware para autenticación ...). Debido a esto, su aplicación ya no está específicamente acoplada a IIS y puede ejecutarla en cualquier servidor web .NET, por ejemplo:Startup clase y algunos componentes de middleware OWIN (OMC) proporcionados por Microsoft. UtilizandoIAppBuilder

• El paquete OwinHost se puede usar para alojar su aplicación con un servidor web Katana.
• El paquete Microsoft.Owin.Host.SystemWeb se usa para alojar su aplicación OWIN en IIS7 + en modo integrado, suscribiendo su middleware a los eventos de vida correctos internamente.

Lo que hace que todo sea tan confuso es que Global.asaxtodavía se admite junto con la Startupclase OWIN , mientras que ambos pueden hacer cosas similares. Por ejemplo, podría implementar CORS Global.asaxy la autenticación utilizando el middleware OWIN, lo que se vuelve realmente confuso.

Mi regla general es eliminar el Global.asaxarchivo por completo a favor de usarlo Startupcada vez que necesite agregar OWIN.

ASP.NET Core

ASP.NET Core es la próxima evolución y ahora puede apuntar a .NET Core o al .NET Framework completo. Cuando apunta a .NET Core, puede ejecutar su aplicación en cualquier host que admita el estándar .NET. Esto significa que ya no está restringido a un servidor web .NET (como en el punto anterior), sino que puede alojar su aplicación en contenedores Docker, un servidor web Linux, IIS ...

El punto de entrada para una aplicación web ASP.NET Core es el Program.csarchivo. Allí configura su host y nuevamente especifica su Startupclase donde configura su canalización. El uso de OWIN (mediante el IAppBuilder.UseOwinmétodo de extensión) es opcional, pero totalmente compatible .