ASP.NET no .NET 11 Preview 5: novidades e melhorias

Feedback instantâneo em páginas SSR

Até aqui, um formulário em SSR estático só descobria erros depois do envio. Por isso, o usuário preenchia tudo, clicava em enviar e só então via que o email estava errado.

Agora, formulários SSR que usam DataAnnotationsValidator validam os campos direto no navegador. O servidor renderiza os metadados das regras, e o script do Blazor aplica essas regras no cliente sem round-trip.

Na prática, a experiência fica equivalente à do MVC com unobtrusive validation e à dos componentes interativos. Além disso, o modelo .NET segue como fonte única das regras.

<EditForm Model="Model" Enhance FormName="registration" OnValidSubmit="HandleValidSubmit">
    <DataAnnotationsValidator />

    <div>
        <label for="Email">Email</label>
        <InputText @bind-Value="Model!.Email" id="Email" />
        <ValidationMessage For="@(() => Model!.Email)" />
    </div>

    <div>
        <label for="Password">Password</label>
        <InputText @bind-Value="Model!.Password" id="Password" type="password" />
        <ValidationMessage For="@(() => Model!.Password)" />
    </div>

    <button type="submit" id="submit-btn">Register</button>
</EditForm>

O recurso vem ligado por padrão e atende formulários enhanced e não enhanced. Portanto, quem já usa Data Annotations ganha a melhoria sem tocar no modelo.

Mesmo assim, mantenha a validação no servidor. O navegador melhora a usabilidade, mas a segurança continua dependendo do que o servidor confere.

Validação assíncrona no Blazor no .NET 11

Verificar se um nome de usuário já existe exige uma consulta ao banco ou a uma API. Até então, esse tipo de regra pedia código manual fora do fluxo de validação do EditForm.

Com o Blazor no .NET 11, o submit do EditForm aguarda os validadores assíncronos em qualquer modo de renderização. Nos modos interativos, um componente validador registra tarefas por campo com EditContext.AddValidationTask.

O framework acompanha essas tarefas e cancela as que ficaram obsoletas, por exemplo quando o usuário digita de novo. Além disso, ele informa o andamento com IsValidationPending(field) e IsValidationFaulted(field).

<EditForm EditContext="editContext" OnSubmit="HandleSubmit">
    <InputText @bind-Value="model.Username" />
    @if (editContext.IsValidationPending(() => model.Username))
    {
        <!-- Mostra o aviso enquanto a checagem assíncrona roda -->
        <span>Checking availability...</span>
    }
    <ValidationMessage For="() => model.Username" />
    <button type="submit">Register</button>
</EditForm>

O Preview 5 entrega apenas os blocos de construção. A integração completa com DataAnnotationsValidator dependia de novas APIs assíncronas de DataAnnotations, previstas para depois.

Segundo a documentação atual, essas APIs chegaram como AsyncValidationAttribute e IAsyncValidatableObject. Também vale notar que o registro por campo passou a se chamar EditContext.RegisterAsyncFieldValidator em versões posteriores.

Mensagens de erro em vários idiomas

O Blazor no .NET 11 também trouxe localização de primeira classe para mensagens de validação e nomes de propriedades. A novidade vale para formulários Blazor e para endpoints de Minimal API.

Por padrão, as traduções vêm de arquivos RESX por idioma, publicados com o assembly. O registro acontece em uma linha:

builder.Services.AddValidation()
    .AddValidationLocalization<ValidationMessages>();
    // Procura ValidationMessages.en.resx, ValidationMessages.pt-BR.resx, ...

O valor de ErrorMessage em cada atributo vira a chave de busca no arquivo de recursos. Dessa forma, o modelo guarda só a chave, e o texto final depende da cultura ativa.

[ValidatableType]
public class ContactModel
{
    [Required(ErrorMessage = "RequiredField")]
    [EmailAddress(ErrorMessage = "InvalidEmail")]
    [Display(Name = "ContactEmail")]
    public string? Email { get; set; }
}

Quem guarda traduções em banco de dados ou JSON pode registrar uma implementação própria de IStringLocalizerFactory. Nesse caso, a implementação do usuário tem precedência sobre o RESX.

Para não repetir chaves em todos os atributos, existe ainda uma estratégia programática:

builder.Services.AddValidation()
    .AddValidationLocalization<ValidationMessages>(options =>
    {
        // Sem ErrorMessage, a chave vira "{NomeDoAtributo}_Error"
        options.ErrorMessageKeyProvider = ctx =>
            ctx.Attribute.ErrorMessage ?? $"{ctx.Attribute.GetType().Name}_Error";
    });

Em projetos com dezenas de modelos, essa centralização reduz duplicação e facilita a inclusão de idiomas. Contudo, versões posteriores tornaram a localização nativa com AddLocalization e AddValidation, então revise o registro ao atualizar.

Mesma cultura na pré-renderização e no cliente

Imagine uma página que mostra valores em reais. Antes, o servidor pré-renderizava com a cultura dele e, depois da hidratação, o cliente refazia a tela com outra formatação.

Agora, aplicações Blazor WebAssembly com pré-renderização persistem o CurrentCulture e o CurrentUICulture do servidor no estado do componente. Em seguida, o cliente aplica essa cultura antes de carregar os assemblies satélite.

Com isso, datas, moedas e números aparecem iguais nas duas etapas. O comportamento vem ligado por padrão para componentes WebAssembly interativos.

Se a sua aplicação deixa o cliente escolher a cultura, desligue a opção:

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents(options =>
    {
        // O cliente define a cultura sozinho
        options.UseCultureFromServer = false;
    });

Sessão HTTP direto no componente

O atributo [SupplyParameterFromSession] segue o mesmo modelo de [SupplyParameterFromQuery] e [SupplyParameterFromForm]. Ou seja, uma propriedade do componente lê e grava um valor da sessão HTTP sem código extra.

Isso serve bem para o ID de um carrinho ou para o passo atual de um formulário em várias etapas. O framework serializa os valores com System.Text.Json e grava tudo antes de enviar a resposta.

@page "/checkout"

<p>Current step: @CurrentStep</p>

<EditForm Model="Input" FormName="checkout" OnSubmit="NextStep">
    <button type="submit">Next</button>
</EditForm>

@code {
    // Lido e gravado na sessão com a chave "checkout-step"
    [SupplyParameterFromSession(Name = "checkout-step")]
    public int CurrentStep { get; set; }

    private object Input { get; } = new();

    private void NextStep() => CurrentStep++;
}

Para funcionar, registre o cache, a sessão e o middleware no Program.cs:

builder.Services.AddDistributedMemoryCache();
builder.Services.AddSession();
builder.Services.AddRazorComponents();

var app = builder.Build();
app.UseSession();

Ao contrário do TempData, o valor não desaparece depois da primeira leitura. Ele fica disponível enquanto a sessão existir.

Proteção contra trailer headers incompletos

O Kestrel agora aplica o RequestHeadersTimeout aos trailer headers fragmentados de HTTP/2 e HTTP/3. Dessa forma, uma conexão não fica aberta para sempre esperando um frame HEADERS que nunca termina.

builder.WebHost.ConfigureKestrel(options =>
{
    // O mesmo limite protege headers iniciais e trailers
    options.Limits.RequestHeadersTimeout = TimeSpan.FromSeconds(10);
});

Em servidores com muita concorrência, isso evita que clientes maliciosos ou com bugs consumam recursos indefinidamente.

Schemas OpenAPI mais fiéis

Parâmetros enum fora do corpo agora mantêm os nomes originais dos membros C#. Isso vale mesmo quando o JsonStringEnumConverter define uma política de nomenclatura, porque query, route, header e form usam Enum.TryParse.

builder.Services.ConfigureHttpJsonOptions(options =>
{
    options.SerializerOptions.Converters.Add(
        new JsonStringEnumConverter(JsonNamingPolicy.KebabCaseLower));
});

app.MapGet("/orders", (OrderStatus status) => Results.Ok(status));

Nesse exemplo, o schema do corpo mostra OrderStatus.PendingReview como pending-review. Já o parâmetro de query aparece como PendingReview, que é o valor que o binding aceita.

Os schemas de arrays também ganharam IDs válidos, como stringArray e TodoArray. Por fim, Minimal APIs aceitam vários Produces<T>() para o mesmo status code, e controllers aceitam vários [ProducesResponseType].

Correções que merecem atenção

No Blazor no .NET 11, a equipe corrigiu uma falha ao renderizar um componente interativo a partir de um layout durante a navegação enhanced. Também incluiu anotações StringSyntaxAttribute.DateTimeFormat nos overloads de DateTimeOffset do BindConverter.

Em Data Protection, o time resolveu a starvation do thread pool no KeyRingProvider durante a inicialização a frio. O problema surgia quando muitos chamadores pediam chaves antes de o key ring entrar em cache.

No Kestrel, mensagens HTTP/2 e HTTP/3 com headers específicos de conexão passam a contar como malformadas, conforme os RFCs 9113 e 9114. Além disso, o servidor fecha a conexão após uma requisição com Content-Length e Transfer-Encoding juntos, como pede o RFC 9112.

Em Minimal APIs, structs opcionais não anuláveis com = default na query deixaram de lançar exceção. Também, application/problem+json e application/problem+xml seguem como tipos preferidos quando o ProducesAttribute define outro tipo.