O que vem por ai no ASP.NET 11

Coleta de feedback multicanal

O processo começa com a coleta de feedback em várias fontes. Entre elas, o time citou:

• Issues no GitHub do ASP.NET Core e de repositórios relacionados.
• Reações nas issues, como o polegar para cima.
• Comentários detalhados e cenários compartilhados pelos usuários.
• Plataformas como Reddit, Discord e fóruns.
• Feedback de clientes internos da Microsoft, que usam a plataforma em escala.
• Clientes externos, com demandas práticas de evolução da stack.
• MVPs e influenciadores técnicos, que funcionam como termômetro das dores do ecossistema.

Esse conjunto de fontes tem um objetivo explícito: reduzir o risco de decisões enviesadas por um único canal. Afinal, uma feature muito discutida no GitHub pode não representar o problema mais relevante em produção.

Da mesma forma, uma dor vivida em escala dentro da Microsoft pode gerar ganhos amplos para todo o ecossistema.

Uso de IA para analisar issues

Um ponto relevante é a adoção de ferramentas de IA para lidar com issues que acumulam dezenas ou centenas de comentários. Com isso, o time não se limita à contagem de reações.

A análise qualitativa considera sinais como:

• Severidade percebida.
• Nível de frustração dos usuários.
• Frequência de ocorrência.
• Existência ou não de alternativas de contorno.

A proposta é acelerar a triagem sem eliminar o julgamento humano. Dessa forma, o custo de leitura e síntese cai, enquanto a decisão continua com as pessoas.

Tendências de mercado e temas macro

Além do feedback do ecossistema, o time considera tendências de mercado e mudanças tecnológicas relevantes para quem desenvolve para a web. No momento, o fator dominante é a consolidação de uma era de IA, com impacto direto em padrões arquiteturais e protocolos emergentes.

Depois de agregar os sinais, o planejamento define temas em alto nível. Esses temas orientam decisões, agrupam iniciativas e dão coerência ao roadmap.

Segundo o encontro, os temas podem surgir de três origens:

• Necessidades reais reportadas pelo público.
• Direções de mercado e padrões emergentes.
• Prioridades de negócio da Microsoft.

Portanto, o roadmap não é apenas uma lista de features técnicas. Na verdade, ele sintetiza o ecossistema, as demandas do mercado e a estratégia corporativa.

Priorização e trade-offs no ASP.NET 11

Com os temas definidos, o time prioriza iniciativas com base em impacto e custo. Algumas ideias são excelentes, mas caras, arriscadas ou demoradas demais para um ciclo anual.

Por isso, o processo inclui estimativas de esforço, avaliação de risco e análise de custo e benefício. Entre as decisões típicas, o time citou:

• Entregar algo menor e de alto impacto rapidamente.
• Evitar projetos que consumiriam anos do time inteiro.
• Equilibrar inovação com a manutenção da base existente.

O roadmap como declaração pública

O roadmap reúne os itens que o time espera entregar, mas ele pode mudar ao longo do ciclo. Embora o objetivo seja previsibilidade, o encontro reforçou três pontos:

• O time atualiza o roadmap quando os planos mudam.
• Prioridades emergentes podem impactar a execução.
• O roadmap funciona como fonte de verdade do plano atual.

Milestone de planejamento não é compromisso

O milestone de planejamento do .NET 11 funciona como um balde de candidatos. Ou seja, nem tudo o que está nele vai sair do papel.

Em contraste, o milestone de backlog indica itens que o time não pretende atacar no curto prazo.

Milestones de preview indicam execução real

À medida que o ciclo avança, os itens migram para milestones de preview, como Preview 1, Preview 2 e assim por diante. Esse movimento é um sinal operacional, porque mostra que alguém assumiu o trabalho e que ele está em andamento.

Então, para saber o que realmente vai chegar ao ASP.NET 11, acompanhe os milestones de preview, e não apenas o de planejamento.

Abrir issues com bugs e sugestões

O primeiro requisito é existir um registro rastreável. Se não há issue, a chance de priorização é baixa.

Reagir e comentar com contexto

As reações ajudam a indicar relevância, mas os comentários com cenários determinam o entendimento técnico. Segundo o time, um feedback útil responde a quatro perguntas:

• O que você está tentando construir.
• Por que isso importa.
• Quão severo é o impacto.
• Se existem alternativas viáveis de contorno.

Revisões de design e propostas de API

A participação pode ir além de sugestões e chegar à coautoria técnica. Por exemplo, você pode revisar pull requests, discutir propostas e escrever design proposals.

O time também mencionou a intenção de voltar a transmitir as revisões de API. Com isso, a transparência aumenta e a comunidade aprende os critérios reais de design.

Contribuições via pull requests

O time afirmou que um pull request não precisa estar no roadmap para ser aceito. Ainda assim, contribuições grandes exigem alinhamento de design, avaliação de risco e análise de manutenção.

A recomendação, portanto, é clara: abra a issue, discuta o design e só então implemente.

Feedback mais votado e fundamentos da plataforma

O planejamento parte do backlog mais votado e comentado. Assim, o time tenta maximizar as melhorias desejadas dentro das restrições de custo e risco.

Ao mesmo tempo, o time reforçou o compromisso com os fundamentos:

• Desempenho como investimento recorrente.
• Segurança como prioridade crítica, inclusive com fuzzing e validações.
• Observabilidade em aplicações distribuídas.
• Confiabilidade e qualidade operacional.

Essa dimensão é estratégica, porque não se trata só de features visíveis. Na prática, o objetivo é tornar as aplicações mais baratas, seguras e previsíveis em produção.

Foco na stack moderna do ASP.NET 11

O ASP.NET Core é uma stack madura, com tecnologias que se sobrepõem. Por isso, o time explicitou onde pretende concentrar a inovação: Minimal APIs, Blazor, SignalR e gRPC.

Enquanto isso, MVC e API Controllers seguem suportados, mas com menos foco de inovação. Em outras palavras, eles ficam mais próximos de um modo de manutenção e compatibilidade.

O artigo sobre o futuro do Blazor no .NET 11 aprofunda o lado da interface.

Aplicações distribuídas com Aspire

O Aspire aparece como parceiro direto do ASP.NET Core para melhorar a experiência de desenvolvimento distribuído. Entre os pontos citados estão:

• Melhor experiência de desenvolvimento local.
• Observabilidade integrada.
• Facilidade de composição de serviços.
• Integração mais suave com Blazor, especialmente WebAssembly.

O encontro sugeriu que essa integração ainda tem arestas. Logo, parte do investimento do ciclo vai para reduzir esse atrito.

Aplicações agentic e IA no desenvolvimento

O time posiciona o ASP.NET 11 como base para aplicações inteligentes e orientadas a agentes. Para isso, citou a integração com o Microsoft Agent Framework, a evolução da interface para padrões conversacionais e multimodais e o suporte a protocolos relevantes de IA.

Nesse sentido, as aplicações deixam de ser apenas formulários e grids. Elas passam a incorporar linguagem natural, contexto e automação.

Além da IA como recurso do produto, o encontro destacou a IA como aceleradora do desenvolvimento. Por exemplo, o time quer tornar o framework mais amigável para assistentes, com melhor integração ao GitHub Copilot e possíveis agentes e MCP servers voltados ao ASP.NET Core.

Native AOT no Blazor do ASP.NET 11

O ASP.NET Core já oferece Native AOT em áreas como Minimal APIs e SignalR, ambos com suporte parcial segundo a documentação de Native AOT. No ciclo do .NET 11, o time pretende iniciar a jornada de Native AOT para o Blazor, com evolução incremental.

O time também enfatizou três ressalvas:

• Native AOT ainda é minoria no ecossistema geral.
• Existem atritos, como a necessidade de declarar os tipos usados na serialização JSON.
• Os investimentos devem ser progressivos e guiados por cenários reais.

O exemplo abaixo mostra esse atrito na prática, porque toda API com Native AOT precisa registrar os tipos em um contexto de serialização gerado em tempo de compilação:

// Registra o contexto de serialização gerado pelo source generator
builder.Services.ConfigureHttpJsonOptions(options =>
{
    options.SerializerOptions.TypeInfoResolverChain.Insert(0, AppJsonSerializerContext.Default);
});

// Declara os tipos que trafegam no corpo das requisições e respostas
[JsonSerializable(typeof(Order[]))]
internal partial class AppJsonSerializerContext : JsonSerializerContext
{
}

Copilot Coding Agent e produtividade

O time confirmou a adoção ativa do Copilot e a existência de pull requests impulsionados por IA, sempre com revisão humana obrigatória. No entanto, a eficiência do agente depende de fechar o ciclo: compilar, executar testes e validar o comportamento.

Em repositórios complexos, como o do próprio ASP.NET Core, isso exige investimento adicional em automação e build.

Versionamento de APIs, identidade e Hot Reload

O versionamento de APIs ainda depende de um pacote mantido fora do time do ASP.NET Core e muito usado pela comunidade. A recomendação foi pragmática, já que o time considera o pacote sólido para o problema.

Sobre identidade, a interface padrão no Blazor usa renderização no servidor, porque o sistema de autenticação depende do contexto da requisição. Embora seja possível introduzir interatividade, existem limitações estruturais.

Quanto ao Hot Reload, o time apontou esforços significativos de desempenho no tooling. Inclusive, as versões Insider já mostram reduções drásticas de tempo em projetos grandes.

DPoP e prova de posse no OAuth

O time considera o suporte a DPoP, mecanismo de prova de posse descrito na RFC 9449. Contudo, ele depende de bibliotecas de identidade que o time do ASP.NET Core não mantém diretamente.

Por isso, a adoção fica condicionada a alinhamentos e entregas em áreas adjacentes.