c# - net - owin authentication mvc 5

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

Question

Digamos, por ejemplo, en una nueva aplicación ASP.NET MVC 5 hecha desde la plantilla MVC w / Individual Accounts, si Global.asax.cs clase Global.asax.cs y muevo su código de configuración al método Startup.cs Configuration() siguiente manera: ¿Cuáles son los inconvenientes?

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 mejor para mí es que al actualizar aplicaciones ASP.NET 4 a ASP.NET 5 y al utilizar piezas que ahora deben configurarse en la clase Startup.cs, no estoy haciendo inyección de dependencia y otras configuraciones en dos clases diferentes que parecen relacionadas a la puesta en marcha, y la configuración.

Answer 1

Para aquellos que buscan los pasos completos: si está buscando crear una API web alojada basada en OWIN, IIS, estos pasos deberían llevarlo 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, agregue Project -> Web -> ASP.NET Web Application (segmentación .NET 4.6)

   3.1 Ahora, en las plantillas de ASP.NET 4.5, elija Vaciar 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    

A continuación, 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 de ApiController , ApiController con el atributo RoutePrefix y el método de acción con Route + HttpGet/PutPost (que representa el verbo Http que está buscando) y debe ser bueno para ir

Answer 2

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 mantuvimos el otro código en Global.asax son:

1. Consistencia con versiones anteriores de MVC. (Aquí es donde todo el mundo espera encontrar este código).
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 invoca si tiene Microsoft.Owin.Host.SystemWeb.dll en su directorio bin. Si elimina esta DLL, dejará de llamar 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 por defecto, 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).

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