Preciso de um arquivo Global.asax.cs se estiver usando uma classe OWIN Startup.cs e mover toda a configuração para lá?

Digamos, por exemplo, em um novo aplicativo ASP.NET MVC 5 criado a partir do modelo MVC com contas individuais, se eu excluir a Global.asax.csclasse e mover o código de configuração para o Startup.cs Configuration()método a seguir, quais são as desvantagens?

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

A vantagem para mim é que, ao atualizar aplicativos ASP.NET 4 para o ASP.NET 5 e usar peças que agora precisam ser configuradas na classe Startup.cs, não estou fazendo injeção de dependência e outras configurações em duas classes diferentes que parecem relacionadas para iniciar e configuração.

A configuração Startup.Configuration é chamada um pouco depois do Application_Start, mas não acho que a diferença seja muito importante na maioria dos casos.

Acredito que os principais motivos pelos quais mantivemos o outro código no Global.asax são:

1. Consistência com versões anteriores do MVC. (É aí que todo mundo atualmente espera encontrar esse código.)
2. Capacidade de adicionar outros manipuladores de eventos. No Global.asax, você pode manipular outros métodos, como Session_Start e Application_Error.
3. Correção em uma variedade de cenários de autenticação. O método Startup.Configuration é chamado apenas se você tiver Microsoft.Owin.Host.SystemWeb.dll no diretório bin. Se você remover esta DLL, ela silenciosamente deixará de chamar Startup.Configuration, o que pode ser difícil de entender.

Acho que o terceiro motivo é o mais importante: não adotamos essa abordagem por padrão, já que alguns cenários não incluem essa DLL e é bom poder alterar as abordagens de autenticação sem invalidar o local onde o código não relacionado (como registro de rota) é colocado.

Mas se nenhum desses motivos se aplicar ao seu cenário, acho que você ficaria bem em usar essa abordagem.

Para quem procura as etapas completas: Se você deseja criar uma API da Web hospedada no IIS, baseada em OWIN, essas etapas devem levá-lo até lá:

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

3. Na solução, clique com o botão direito do mouse em adicionar Project -> Web -> ASP.NET Web Application(direcionando-se ao .NET 4.6)

   3.1 Agora nos modelos do ASP.NET 4.5, escolha Vazio como modelo

   3.2 Isso cria uma solução em branco com dois pacotes de nuget:

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

4. Instale os seguintes pacotes:

   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    

Em seguida, adicione Startup.cs com o método de configuração:

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

Agora adicione uma classe que herda de ApiController, anote-a com RoutePrefixatributo e o método de ação com Route + HttpGet/PutPost(representando o verbo Http que você procura) e você deve estar pronto

Este é o meu entendimento de como o início / hospedagem de um aplicativo Web evoluiu, pois é bastante confuso para seguir. Um pequeno resumo:

1. ASP.NET clássico: escreva apenas o código do aplicativo a ser executado na última etapa do pipeline obrigatório do IIS

2. ASP.NET com OWIN: configure um servidor da Web .NET e escreva o código do aplicativo. Como não está mais diretamente associado ao IIS, não é mais necessário usá-lo.

3. ASP.NET Core: configure o host e o servidor da web para usar e escrever o código do aplicativo. Não é mais obrigatório usar um servidor da Web .NET se você segmentar o .NET Core em vez do .NET Framework completo.

Agora, vou detalhar um pouco mais como ele funciona e quais classes são usadas para iniciar o aplicativo:

ASP.NET clássico

Aplicativos clássicos do ASP.NET têm o Global.asaxarquivo como ponto de entrada. Esses aplicativos podem ser executados apenas no IIS e seu código é executado no final do pipeline do IIS (portanto, o IIS é responsável pelo CORS, pela autenticação ... antes mesmo que o seu código seja executado). Desde o IIS 7, você pode executar seu aplicativo no modo integrado, que integra o tempo de execução do ASP.NET ao IIS. Isso permite que seu código configure funcionalidades que antes não eram possíveis (ou apenas no IIS), como a reescrita de URL no Application_Startcaso do seu Global.asaxarquivo ou use a nova <system.webserver>seção do web.configarquivo.

ASP.NET com OWIN

Antes de tudo, o OWIN não é uma biblioteca, mas uma especificação de como os servidores da Web .NET (por exemplo, IIS) interagem com os aplicativos da Web. A própria Microsoft possui uma implementação do OWIN chamada projeto Katana (distribuída por vários pacotes NuGet diferentes). Essa implementação fornece a IAppBuilderinterface que você encontra em uma Startupclasse e alguns OMCs (componentes de middleware) fornecidos pela Microsoft. UsandoIAppBuildervocê basicamente compõe o middleware de forma plug-and-play para criar o pipeline para o servidor da Web (além do pipeline do ASP.NET no IIS7 +, como no ponto acima), em vez de estar vinculado ao pipeline do IIS (mas agora você usa um componente de middleware para CORS, um componente de middleware para autenticação ...). Por esse motivo, seu aplicativo não está mais associado especificamente ao IIS e você pode executá-lo em qualquer servidor Web .NET, por exemplo:

• O pacote OwinHost pode ser usado para auto-hospedar seu aplicativo com um servidor da Web Katana.
• O pacote Microsoft.Owin.Host.SystemWeb é usado para hospedar seu aplicativo OWIN no IIS7 + no modo integrado, assinando internamente o seu middleware para os eventos de duração corretos.

O que torna tudo tão confuso é que Global.asaxainda é suportado junto com a Startupclasse OWIN , enquanto ambos podem fazer coisas semelhantes. Por exemplo, você pode implementar o CORS Global.asaxe a autenticação usando o middleware OWIN, o que se torna realmente confuso.

Minha regra geral é remover o Global.asaxarquivo em geral, em favor do uso Startupsempre que eu precisar adicionar o OWIN.

ASP.NET Core

O ASP.NET Core é a próxima evolução e agora você pode segmentar o .NET Core ou o .NET Framework completo. Ao direcionar o .NET Core, você pode executar seu aplicativo em qualquer host que suporte o .NET Standard. Isso significa que você não está mais restrito a um servidor web .NET (como no ponto anterior), mas pode hospedar seu aplicativo em contêineres Docker, um servidor web linux, IIS ...

O ponto de entrada para um aplicativo Web ASP.NET Core é o Program.csarquivo. Lá você configura seu host e especifica novamente sua Startupclasse onde você configura seu pipeline. O uso do OWIN (usando o IAppBuilder.UseOwinmétodo de extensão) é opcional, mas é totalmente suportado .