Novidades no ASP.NET Core em .NET 11

Este artigo destaca as mudanças mais significativas no ASP.NET Core no .NET 11, com ligações para documentação relevante.

Este artigo será atualizado à medida que novas versões de visualização forem disponibilizadas.

Blazor

Esta seção descreve as novas funcionalidades para Blazor.

Novo DisplayName componente e suporte para [Display] e [DisplayName] atributos

O DisplayName componente pode ser usado para mostrar nomes de propriedades a partir de atributos de metadados:

[Required, DisplayName("Production Date")]
public DateTime ProductionDate { get; set; }

O [Display] atributo na propriedade de classe modelo é suportado:

[Required, Display(Name = "Production Date")]
public DateTime ProductionDate { get; set; }

Das duas abordagens, recomenda-se o [Display] atributo, que disponibiliza propriedades adicionais. O [Display] atributo também permite atribuir um tipo de recurso para localização. Quando ambos os atributos estão presentes, [Display] tem precedência sobre [DisplayName]. Se nenhum dos atributos estiver presente, o componente volta ao nome da propriedade.

Utilize o componente DisplayName em rótulos ou cabeçalhos de tabelas.

<label>
    <DisplayName For="@(() => Model!.ProductionDate)" />
    <InputDate @bind-Value="Model!.ProductionDate" />
</label>

Blazor Formato de opções de arranque de scripts web agora suportado para Blazor Server e Blazor WebAssembly scripts

O objeto de opções script Blazor Web App (blazor.web.js) passado para Blazor.start() utiliza o seguinte formato desde o lançamento do .NET 8:

Blazor.start({
  ssr: { ... },
  circuit: { ... },
  webAssembly: { ... },
});

Os scripts Blazor Server (blazor.server.js) e Blazor WebAssembly (blazor.webassembly.js) podem usar o mesmo formato de opções, agora.

O exemplo seguinte mostra o formato de opções anterior, que continua suportado:

Blazor.start({
  loadBootResource: function (...) {
      ...
    },
  });

O novo formato de opções suportado para o exemplo anterior:

Blazor.start({
  webAssembly: {
    loadBootResource: function (...) {
      ...
    },
  },
});

Para mais informações, consulte ASP.NET Core Blazor startup.

Novo BasePath componente

Blazor Web Apps pode usar o novo BasePath componente (<BasePath />) para renderizar automaticamente a etiqueta HTML do caminho base da aplicação (<base href>). Para mais informações, consulte ASP.NET Core Blazor app base path.

Gestor de eventos inline JS removido do componente NavMenu

No componente JS do modelo de projeto NavMenu, o manipulador de eventos inline Blazor Web App que alterna a exibição dos links de navegação já não está presente. As aplicações geradas a partir do modelo de projeto usam agora uma abordagem de módulo colocado JS para mostrar ou ocultar a barra de navegação na página renderizada. A nova abordagem melhora a conformidade com a Política de Segurança de Conteúdo (CSP) porque não exige que o CSP inclua um hash inseguro para o inline JS.

Para migrar uma aplicação existente para .NET 11, incluindo adotar a nova abordagem de módulo JS para o comutador da barra de navegação, veja Migrar de ASP.NET Core em .NET 10 para ASP.NET Core em .NET 11.

O novo RelativeToCurrentUri parâmetro (predefinido: false) para NavigationManager.NavigateTo e o NavLink componente permite-lhe navegar até URIs relativos ao caminho da página atual, em vez do URI base da aplicação.

Considere os seguintes pontos finais aninhados:

  • /docs
    • /getting-started
      • /installation
      • /configuration

Quando o URI do navegador é /docs/getting-started/installation e quer direcionar o utilizador para /docs/getting-started/configuration, NavigateTo("/configuration") redireciona para /configuration na raiz da aplicação, ao invés de um caminho relativo em /docs/getting-started/configuration. Defina o RelativeToCurrentUri com NavigateTo ou o componente NavLink para a navegação que deseja:

Navigation.NavigateTo("/configuration", new NavigationOptions
{
    RelativeToCurrentUri = true
});

<NavLink href="configuration" RelativeToCurrentUri="true">Configuration</NavLink>

Persistir dados temporários entre pedidos HTTP durante renderização estática do lado do servidor (SSR estático)

Para persistir dados temporários entre pedidos HTTP durante renderização estática do lado do servidor (SSR estático), Blazor suporta TempData. O TempData é ideal para cenários como mensagens flash após submissão de formulários, passagem de dados durante redirecionamentos (padrão POST-Redirect-GET) e notificações únicas.

O TempData está disponível quando AddRazorComponents é chamado no ficheiro da Program aplicação e é fornecido como um valor em cascata com o [CascadingParameter] atributo.

[CascadingParameter]
public ITempData? TempData { get; set; }

Para mais informações, consulte ASP.NET Core Blazor gestão do estado do lado do servidor.

Novo Blazor modelo de Web Worker (blazorwebworker)

Blazor WebAssembly as aplicações podem realizar cálculos pesados no cliente, mas fazê-lo no thread da interface interfere com a renderização da interface e afeta negativamente a experiência do utilizador. No .NET 10, adicionámos um artigo com uma aplicação de exemplo para facilitar a transferência de trabalho pesado do thread da interface para um Web Worker. Para .NET 11, adicionámos o modelo de projeto Web Worker Blazor (blazorwebworker), que fornece infraestrutura para executar código .NET num Web Worker em aplicações Blazor WebAssembly. Para obter mais informações, consulte ASP.NET Core Blazor com .NET em Web Workers.

Virtualize adapta-se a itens de altura variável em tempo de execução

O Virtualize<TItem> componente já não assume que todos os itens têm a mesma altura. O componente agora adapta-se aos tamanhos medidos dos itens em tempo de execução, o que reduz o espaçamento e o deslocamento incorretos quando as alturas dos itens variam. Estas atualizações incluem uma atualização do valor padrão de Virtualize<TItem>.OverscanCount, que era 3 em .NET 10 ou antes e que agora muda para 15 em .NET 11 ou posterior. A alteração no valor padrão aumenta a precisão dos cálculos médios da altura dos itens.

Para mais informações, consulte as secções Tamanho do item e Contagem de overscan na virtualização de componentes do ASP.NET Core Razor.

Blazor Hybrid

Esta seção descreve as novas funcionalidades para Blazor Hybrid.

As notas de lançamento aparecem nesta secção à medida que as funcionalidades de pré-visualização ficam disponíveis.

SignalR

Esta seção descreve as novas funcionalidades para SignalR.

APIs mínimas

Esta secção descreve novas funcionalidades para APIs Mínimas.

OpenAPI

Esta seção descreve os novos recursos para OpenAPI.

Descrever respostas binárias de ficheiros

O ASP.NET Core 11 introduz suporte para gerar descrições OpenAPI para operações que retornam respostas binárias de ficheiros. Este suporte mapeia o FileContentResult tipo de resultado para um esquema OpenAPI com type: string e format: binary.

Use o Produces<T> método de extensão com T de FileContentResult para especificar o tipo de resposta e o tipo de conteúdo:

app.MapPost("/filecontentresult", () =>
{
    var content = "This endpoint returns a FileContentResult!"u8.ToArray();
    return TypedResults.File(content);
})
.Produces<FileContentResult>(contentType: MediaTypeNames.Application.Octet);

O documento OpenAPI gerado descreve a resposta do endpoint como:

responses:
  '200':
    description: OK
    content:
      application/octet-stream:
        schema:
          $ref: '#/components/schemas/FileContentResult'

O FileContentResult é definido em components/schemas como:

components:
  schemas:
    FileContentResult:
      type: string
      format: binary

Suporte OpenAPI 3.2.0 (Breaking Change)

O Microsoft.AspNetCore.OpenApi agora suporta o OpenAPI 3.2.0 através de uma dependência atualizada no Microsoft.OpenApi 3.3.1. Esta atualização inclui alterações que interrompem a biblioteca subjacente. Para mais informações, consulte o Microsoft. Guia de atualização OpenAPI.

Para gerar um documento OpenAPI 3.2.0, especifique a versão ao chamar AddOpenApi:

builder.Services.AddOpenApi(options =>
{
    options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_2;
});

As atualizações subsequentes aproveitam novas capacidades na especificação 3.2.0, como o suporte a esquemas de itens para streaming de eventos.

Obrigado @baywet por esta contribuição!

Autenticação e autorização

Esta seção descreve os novos recursos para autenticação e autorização.

TimeProvider suporte em ASP.NET Core Identity

ASP.NET Core Identity agora usa TimeProvider em vez de DateTime e DateTimeOffset para todas as operações relacionadas com o tempo. Esta alteração torna Identity os componentes mais testáveis e proporciona melhor controlo ao longo do tempo em testes e cenários especializados.

O exemplo seguinte mostra como usar uma falsificação TimeProvider para testar Identity funcionalidades:

// In tests
var fakeTimeProvider = new FakeTimeProvider(
    new DateTimeOffset(2024, 1, 1, 0, 0, 0, TimeSpan.Zero));

services.AddSingleton<TimeProvider>(fakeTimeProvider);
services.AddIdentity<IdentityUser, IdentityRole>();

// Identity will now use the fake time provider

Ao usar TimeProvider, pode escrever mais facilmente testes determinísticos para funcionalidades sensíveis Identity ao tempo, como expiração de tokens, durações de bloqueio e validação de carimbos de segurança.

Inferir o nome de exibição da chave de acesso a partir do autenticador

ASP.NET Core Identity agora infere automaticamente nomes de exibição amigáveis para chaves de acesso com base no seu AAGUID (Authenticator Attestation GUID). Os mapeamentos incorporados estão incluídos para os autenticadores de passkey mais utilizados, incluindo o Google Password Manager, iCloud Keychain, Windows Hello, 1Password e Bitwarden.

Para autenticadores conhecidos, o nome é atribuído automaticamente sem necessidade de ser solicitado ao utilizador. Para autenticadores desconhecidos, o utilizador é redirecionado para uma página de renomeação. Estenda os mapeamentos adicionando entradas ao PasskeyAuthenticators dicionário no projeto.

Miscellaneous

Esta secção descreve várias novas funcionalidades no .NET 11.

IOutputCachePolicyProvider Interface

ASP.NET Core em .NET 11 fornece a interface [IOutputCachePolicyProvider](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/[IOutputCachePolicyProvider.cs](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/IOutputCachePolicyProvider.cs)' para implementar a lógica personalizada de seleção de políticas de cache de saída. Ao utilizar esta interface, as aplicações podem determinar a política padrão de cache base, verificar a existência de políticas nomeadas e suportar cenários avançados onde as políticas devem ser resolvidas dinamicamente. Exemplos incluem carregar políticas a partir de fontes de configuração externas, bases de dados ou aplicar regras de cache específicas para o inquilino.

O código seguinte mostra a IOutputCachePolicyProvider interface:

public interface IOutputCachePolicyProvider
{
    IReadOnlyList<IOutputCachePolicy> GetBasePolicies();
    ValueTask<IOutputCachePolicy?> GetPolicyAsync(string policyName);
}

Obrigado @lqlive por esta contribuição!

Certificados de desenvolvimento com confiança automática em WSL

A configuração de certificados de desenvolvimento agora confia automaticamente nos certificados em ambientes WSL (Subsistema Windows para Linux). Quando executa dotnet dev-certs https --trust em WSL, o certificado é automaticamente instalado e confiável tanto no ambiente WSL como na Windows, eliminando a configuração manual de confiança.

# Automatically trusts certificates in both WSL and Windows
dotnet dev-certs https --trust

Esta melhoria simplifica a experiência de desenvolvimento ao utilizar WSL, eliminando um ponto de atrito comum para programadores que trabalham em ambientes Linux no Windows.

Obrigado @StickFun por esta contribuição!

Rastreamento nativo OpenTelemetry para ASP.NET Core

ASP.NET Core agora adiciona nativamente atributos da convenção semântica OpenTelemetry à atividade do servidor HTTP, alinhando-se com a especificação de intervalo do servidor HTTP OpenTelemetry. Todos os atributos exigidos estão incluídos por defeito, correspondendo aos metadados anteriormente disponíveis apenas através da OpenTelemetry.Instrumentation.AspNetCore biblioteca.

Para recolher os dados de rastreio incorporados, subscreva a fonte de atividade Microsoft.AspNetCore na sua configuração OpenTelemetry:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource("Microsoft.AspNetCore")
        .AddConsoleExporter());

Não é necessária nenhuma biblioteca adicional de instrumentação (como OpenTelemetry.Instrumentation.AspNetCore). A estrutura agora preenche diretamente atributos de convenção semântica na atividade de pedido, como http.request.method, url.path, http.response.status_code, e server.address.

Se não quiseres que os atributos do OpenTelemetry sejam adicionados à atividade, podes desligá-la definindo a opção Microsoft.AspNetCore.Hosting.SuppressActivityOpenTelemetryData AppContext para true.

Melhorias de desempenho

Kestrelo parser de pedidos HTTP/1.1 de 's usa agora um caminho de código sem lançamento para lidar com pedidos malformados. Em vez de lançar BadHttpRequestException em cada falha de análise, o parser devolve uma estrutura de resultados indicando estados de sucesso, incompleto ou erro. Em cenários com muitos pedidos mal formados — como varredura de portas, tráfego malicioso ou clientes mal configurados — isto elimina a sobrecarga dispendiosa de gestão de exceções e melhora o throughput em até 20-40%. Não há impacto no processamento válido dos pedidos.

O middleware de registo HTTP agora agrupa as suas ResponseBufferingStream instâncias, reduzindo as alocações por pedido quando o registo do corpo de resposta ou interceptores estão ativados.

Compressão de resposta Zstandard e descompressão por pedido

ASP.NET Core agora suporta Zstandard (zstd) tanto para compressão de resposta como para descompressão de pedidos. Isto adiciona suporte para zstd ao middleware existente, que faz compressão de resposta e descompressão de pedidos, e ativa o zstd por padrão.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions
    {
        Quality = 6 // 1-22, higher = better compression, slower
    };
});

Obrigado @manandre por esta contribuição!

O HTTP/3 começa a processar pedidos mais cedo

Kestrel agora começa a processar pedidos HTTP/3 sem primeiro esperar pelo fluxo de controlo e pelo quadro SETTINGS, o que reduz a latência do primeiro pedido em novas ligações.

Alterações de grande impacto

Use os artigos em Alterações em .NET para encontrar alterações que possam aplicar-se ao atualizar uma aplicação para uma versão mais recente do .NET.

  • Last updated on