Inicialização do aplicativo

Os aplicativos desenvolvidos para ASP.NET normalmente têm um arquivo global.asax.cs que define o evento Application_Start que controla quais serviços são configurados e disponibilizados para renderização HTML e processamento do .NET. Este capítulo analisa as pequenas diferenças entre ASP.NET Core e o Blazor Server.

Application_Start e Web Forms

O propósito do método padrão Application_Start de web forms aumentou ao longo dos anos para lidar com muitas tarefas de configuração. Um novo projeto de web forms com o modelo padrão no Visual Studio 2022 agora contém a seguinte lógica de configuração:

• RouteConfig – roteamento de URL do aplicativo
• BundleConfig – agrupamento e minificação de CSS e JavaScript

Cada um desses arquivos individuais reside na pasta App_Start e é executado apenas uma vez, no início do nosso aplicativo. RouteConfig no modelo de projeto padrão, adiciona FriendlyUrlSettings para web forms para permitir que as URLs do aplicativo omitam a extensão de arquivo .ASPX. O modelo padrão também contém uma diretiva que fornece códigos de status de redirecionamento HTTP permanentes (HTTP 301) das páginas .ASPX para a URL amigável com o nome do arquivo que omite a extensão.

Com o ASP.NET Core e o Blazor, esses métodos são simplificados e consolidados na classe Startup ou são eliminados em favor de tecnologias comuns da Web.

Estrutura de inicialização do Blazor Server

Os aplicativos do Blazor Server residem em uma versão ASP.NET Core 3.0 ou posterior. Os aplicativos Web do ASP.NET Core são configurados em Program.cs ou por meio de um par de métodos na classe Startup.cs. Um arquivo Program. cs de exemplo é mostrado abaixo:

using BlazorApp1.Data;
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Web;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();
builder.Services.AddSingleton<WeatherForecastService>();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.MapBlazorHub();
app.MapFallbackToPage("/_Host");

app.Run();

Os serviços necessários do aplicativo são adicionados à coleção Services da instância WebApplicationBuilder. É assim que os vários serviços de estrutura do ASP.NET Core são configurados com o contêiner de injeção de dependência interno da estrutura. Os vários métodos builder.Services.Add* adicionam serviços que permitem recursos, como autenticação, Razor Pages, roteamento de controlador de MVC, SignalR e interações do Blazor Server, entre muitos outros. Esse método não era necessário nos web forms, pois a análise e o tratamento dos arquivos ASPX, ASCX, ASHX e ASMX eram definidos referenciando ASP.NET no arquivo de configuração web.config. Mais informações sobre a injeção de dependência no ASP.NET Core estão disponíveis na documentação online.

Após a criação de app por builder, as demais chamadas em app configuram seu pipeline HTTP. Com essas chamadas, declaramos de cima para baixo o Middleware que processará todas as solicitações enviadas ao nosso aplicativo. A maioria desses recursos na configuração padrão foi espalhada pelos arquivos de configuração dos web forms e agora estão em um só lugar para facilitar a referência.

A configuração da página de erro personalizada não é mais colocada em um arquivo web.config. Agora, está configurada para sempre ser mostrada quando o ambiente do aplicativo não tiver o rótulo Development. Além disso, os aplicativos do ASP.NET Core agora estão configurados para servir páginas seguras com TLS por padrão com a chamada de método UseHttpsRedirection.

Em seguida, uma chamada inesperada do método de configuração é feita para UseStaticFiles. No ASP.NET Core, o suporte para solicitações de arquivos estáticos (como JavaScript, CSS e arquivos de imagem) deve ser habilitado explicitamente e somente arquivos na pasta wwwroot do aplicativo são endereçáveis publicamente por padrão.

A próxima linha é a primeira que replica uma das opções de configuração dos web forms: UseRouting. Esse método adiciona o roteador do ASP.NET Core ao pipeline e pode ser configurado aqui ou nos arquivos individuais para os quais ele pode considerar o roteamento. Mais informações sobre a configuração de roteamento podem ser encontradas na seção sobre roteamento.

As chamadas finais app.Map* nesta seção definem os pontos de extremidade que ASP.NET Core está escutando. Essas rotas são os locais acessíveis na Web que você pode acessar no servidor Web e receber algum conteúdo processado pelo .NET e retornado a você. A primeira entrada, MapBlazorHub configura um hub SignalR para uso no fornecimento da conexão persistente e em tempo real com o servidor em que o estado e a renderização dos componentes do Blazor são processados. A chamada de método MapFallbackToPage indica o local acessível pela Web da página que inicia o aplicativo do Blazor e configura o aplicativo para processar solicitações de vinculação profunda do cliente. Você verá esse recurso funcionando se abrir um navegador e navegar diretamente até a rota processada do Blazor no seu aplicativo, como /counter no modelo de projeto padrão. A solicitação é processada pela página de fallback _Host.cshtml, que executa o roteador do Blazor e renderiza a página do contador.

A última linha inicia o aplicativo, algo que não era necessário nos web forms (uma vez que dependia do IIS estar em execução).

Atualizando o processo BundleConfig

As tecnologias de agrupamento de ativos como folhas de estilos CSS e arquivos JavaScript mudaram significativamente, com outras tecnologias fornecendo ferramentas e técnicas em rápida evolução para gerenciar esses recursos. Para isso, recomendamos usar uma ferramenta de linha de comando do Node, como Grunt/Gulp/WebPack, para empacotar seus ativos estáticos.

As ferramentas de linha de comando Grunt, Gulp e WebPack e suas configurações associadas podem ser adicionadas ao seu aplicativo e o ASP.NET Core ignorará silenciosamente esses arquivos durante o processo de build do aplicativo. Você pode adicionar uma chamada para executar as tarefas adicionando um Target ao arquivo de projeto com sintaxe semelhante à seguinte que dispararia um script gulp e o destino min dentro desse script:

<Target Name="MyPreCompileTarget" BeforeTargets="Build">
  <Exec Command="gulp min" />
</Target>

Mais detalhes sobre ambas as estratégias de gerenciamento dos seus arquivos CSS e JavaScript estão disponíveis na documentação Empacotar e minificar ativos estáticos no ASP.NET Core.