Inicialização do aplicativo
Gorjeta
Este conteúdo é um excerto do eBook, Blazor for ASP NET Web Forms Developers for Azure, disponível no .NET Docs ou como um PDF transferível gratuito que pode ser lido offline.
Os aplicativos que são escritos para ASP.NET normalmente têm um global.asax.cs arquivo que define o evento que controla Application_Start quais serviços são configurados e disponibilizados para renderização HTML e processamento .NET. Este capítulo analisa como as coisas são ligeiramente diferentes com o ASP.NET Core e o Blazor Server.
Application_Start e Web Forms
O método de formulários Application_Start da Web padrão cresceu em propósito ao longo dos anos para lidar com muitas tarefas de configuração. Um novo projeto de formulários da Web com o modelo padrão no Visual Studio 2022 agora contém a seguinte lógica de configuração:
RouteConfig- Roteamento de URL do aplicativoBundleConfig- Agregação e minificação de CSS e JavaScript
Cada um desses arquivos individuais reside na App_Start pasta e é executado apenas uma vez no início do nosso aplicativo. RouteConfig no modelo de projeto padrão, adiciona os FriendlyUrlSettings formulários for Web para permitir que as URLs do aplicativo omitam a extensão do .ASPX arquivo. O modelo padrão também contém uma diretiva que fornece códigos de status de redirecionamento HTTP permanentes (HTTP 301) para as .ASPX páginas para a URL amigável com o nome de arquivo que omite a extensão.
Com ASP.NET Core e Blazor, esses métodos são simplificados e consolidados na Startup classe ou são eliminados em favor de tecnologias web comuns.
Estrutura de inicialização do Blazor Server
Os aplicativos Blazor Server residem em cima de uma versão ASP.NET Core 3.0 ou posterior. ASP.NET aplicativos Web principais são configurados em Program.cs ou por meio de um par de métodos na Startup.cs classe. Um exemplo de arquivo Program.cs é 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 à WebApplicationBuilder coleção da Services instância. É assim que os vários serviços da estrutura ASP.NET Core são configurados com o contêiner de injeção de dependência interno da estrutura. Os vários builder.Services.Add* métodos adicionam serviços que permitem recursos como autenticação, páginas de barbear, roteamento do controlador MVC, interações SignalR e Blazor Server, entre muitos outros. Esse método não era necessário em formulários da Web, pois a análise e o tratamento dos arquivos ASPX, ASCX, ASHX e ASMX eram definidos fazendo referência a 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 on-line.
Depois que o app tiver sido criado pelo builder, o restante das chamadas em app configurar seu pipeline HTTP. Com essas chamadas, declaramos de cima para baixo o Middleware que lidará com todas as solicitações enviadas ao nosso aplicativo. A maioria desses recursos na configuração padrão foram espalhados pelos arquivos de configuração de formulários da Web 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 web.config arquivo, mas agora está configurada para ser sempre mostrada se o ambiente do aplicativo não estiver rotulado Development. Além disso, os aplicativos ASP.NET Core agora estão configurados para servir páginas seguras com TLS por padrão com a chamada de UseHttpsRedirection método.
Em seguida, uma chamada de método de configuração inesperada é 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 explicitamente habilitado, e apenas os arquivos na pasta wwwroot do aplicativo são publicamente endereçáveis por padrão.
A próxima linha é a primeira que replica uma das opções de configuração de formulários da Web: UseRouting. Esse método adiciona o roteador 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 Roteamento.
As chamadas finais app.Map* nesta seção definem os pontos de extremidade nos quais ASP.NET Core está escutando. Essas rotas são os locais acessíveis pela Web que você pode acessar no servidor Web e receber algum conteúdo manipulado pelo .NET e devolvido a você. A primeira entrada, MapBlazorHub configura um hub SignalR para uso no fornecimento de conexão persistente e em tempo real para o servidor onde o estado e a renderização dos componentes Blazor são manipulados. A MapFallbackToPage chamada de método indica o local acessível pela Web da página que inicia o aplicativo Blazor e também configura o aplicativo para lidar com solicitações de vinculação profunda do lado do cliente. Você verá esse recurso no trabalho se abrir um navegador e navegar diretamente para a rota manipulada pelo Blazor em seu aplicativo, como /counter no modelo de projeto padrão. A solicitação é tratada pela página de fallback _Host.cshtml , que executa o roteador Blazor e renderiza a página do contador.
A última linha inicia o aplicativo, algo que não era necessário em formulários da Web (já que dependia do IIS para ser executado).
Atualizando o processo BundleConfig
As tecnologias para agregar ativos, como folhas de estilo 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 o uso de uma ferramenta de linha de comando 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 ASP.NET Core ignorará silenciosamente esses arquivos durante o processo de compilação do aplicativo. Você pode adicionar uma chamada para executar suas tarefas adicionando um Target dentro do seu arquivo de projeto com sintaxe semelhante à seguinte que acionaria um script gulp e o min destino dentro desse script:
<Target Name="MyPreCompileTarget" BeforeTargets="Build">
<Exec Command="gulp min" />
</Target>
Mais detalhes sobre ambas as estratégias para gerenciar seus arquivos CSS e JavaScript estão disponíveis no Bundle e minificam ativos estáticos na documentação ASP.NET Core .
