Dotnet | The .NET Blog

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 acontece de 11 a 15 de maio de 2026 no Barbican Centre em Londres. A conferência principal de 3 dias vai de terça a quinta, com workshops opcionais de dia inteiro na segunda e na sexta.

Com 78 sessões e 14 workshops, é uma das conferências mais completas para desenvolvedores na Europa.

Tópicos

Pensamento Arquitetural
Código Funcional em C# 13
Design Serverless
IA Semântica
Azure Kubernetes Services
Estratégias Lean DevOps
The Model Context Protocol (MCP)
IA Agêntica em .NET
Refatorando o Monolito
Programar Mais Rápido com LLMs
Criptografia em um Mundo Pós-Quântico
Desenvolvimento Local First

Palestrantes

Elenco de classe mundial incluindo Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm e Raju Gandhi.

Ingressos e informações

98% dos participantes do SDD 2025 avaliaram a experiência geral como boa, muito boa ou excelente.

Hooks do azd em Python, TypeScript e .NET: chega de scripts shell

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Esta publicação foi traduzida automaticamente. Para a versão original, clique aqui.

Se você já teve um projeto completamente em .NET e mesmo assim precisou escrever scripts Bash para os hooks do azd, conhece bem essa dor. Por que mudar para sintaxe de shell num passo de pré-provisioning quando tudo o mais no projeto é C#?

Essa frustração agora tem uma solução oficial. A CLI do Azure Developer acaba de lançar suporte a múltiplos idiomas para hooks, e é exatamente tão bom quanto parece.

Hooks, brevemente

Hooks são scripts que rodam em pontos-chave do ciclo de vida do azd — antes do provisioning, após o deployment e mais. São definidos no azure.yaml e permitem injetar lógica customizada sem modificar a CLI.

Antes, apenas Bash e PowerShell eram suportados. Agora você pode usar Python, JavaScript, TypeScript ou .NET — e o azd cuida do resto automaticamente.

Como funciona a detecção

Basta apontar o hook para um arquivo e o azd infere o idioma pela extensão:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Sem configuração extra. Se a extensão for ambígua, você pode adicionar kind: python (ou o que for) para especificar explicitamente.

Detalhes por linguagem

Python

Coloque um requirements.txt ou pyproject.toml ao lado do script (ou em um diretório pai). O azd cria automaticamente um ambiente virtual, instala dependências e executa o script.

JavaScript e TypeScript

Mesmo padrão — coloque um package.json perto do script e o azd executará npm install primeiro. Para TypeScript, usa npx tsx sem etapa de compilação e sem tsconfig.json.

.NET

Dois modos disponíveis:

Modo projeto: Se houver um .csproj ao lado do script, o azd executa dotnet restore e dotnet build automaticamente.
Modo single-file: No .NET 10+, arquivos .cs independentes executam diretamente via dotnet run script.cs. Sem arquivo de projeto.

Configuração por executor

Cada linguagem suporta um bloco config opcional:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Por que isso importa para desenvolvedores .NET

Os hooks eram o último lugar num projeto baseado em azd que forçava uma troca de linguagem. Agora todo o pipeline de deployment pode viver em um único idioma. Você pode reutilizar utilitários .NET existentes em hooks, referenciar bibliotecas compartilhadas e abandonar a manutenção de scripts shell.

Conclusão

Um desses mudanças que parecem pequenas, mas que removem muita fricção do dia a dia com azd. O suporte multi-linguagem para hooks já está disponível — confira o post oficial para a documentação completa.

Windows App Dev CLI v0.3: F5 a partir do terminal e automação de UI para agentes

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Esta publicação foi traduzida automaticamente. Para a versão original, clique aqui.

A experiência F5 do Visual Studio é fantástica. Mas ter que abrir o VS só para lançar e depurar uma app Windows empacotada é demais — seja num pipeline de CI, num workflow automatizado, ou quando um agente de IA está fazendo os testes.

Windows App Development CLI v0.3 acabou de ser lançada e aborda isso diretamente com dois recursos principais: winapp run e winapp ui.

winapp run: F5 a partir de qualquer lugar

winapp run recebe uma pasta de app não empacotada e um manifesto, e faz tudo que o VS faz num debug launch: registra um pacote loose, lança a app e preserva o LocalState entre re-deploys.

# Compilar a app e então executá-la como app empacotada
winapp run ./bin/Debug

Funciona para WinUI, WPF, WinForms, Console, Avalonia e mais. Os modos são pensados para desenvolvedores e workflows automatizados:

--detach: Lança e devolve o controle ao terminal imediatamente. Perfeito para CI.
--unregister-on-exit: Limpa o pacote registrado ao fechar a app.
--debug-output: Captura mensagens OutputDebugString e exceções em tempo real.

Novo pacote NuGet: dotnet run para apps empacotadas

Para desenvolvedores .NET há um novo pacote NuGet: Microsoft.Windows.SDK.BuildTools.WinApp. Após a instalação, dotnet run cuida de todo o inner loop: build, preparar um pacote loose-layout, registrar no Windows e lançar — tudo em uma etapa.

winapp init
# ou
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: UI Automation a partir da linha de comando

Este é o recurso que abre os cenários agênticos. winapp ui fornece acesso completo de UI Automation a qualquer app Windows em execução — WPF, WinForms, Win32, Electron, WinUI3 — diretamente do terminal.

O que é possível fazer:

Listar todas as janelas de nível superior
Navegar pela árvore completa de UI Automation de uma janela
Procurar elementos por nome, tipo ou ID de automação
Clicar, invocar e definir valores
Tirar screenshots
Aguardar o aparecimento de elementos — ideal para sincronização de testes

Combinar winapp ui com winapp run cria um workflow completo build → lançar → verificar a partir do terminal. Um agente pode executar a app, inspecionar o estado da UI e validar o resultado.

Outras novidades

winapp unregister: Remove um pacote sideloaded quando terminar.
winapp manifest add-alias: Adiciona um alias para lançar a app por nome a partir do terminal.
Tab completion: Configure o completamento PowerShell com um único comando.

Como obter

winget install Microsoft.WinAppCli
# ou
npm install -g @microsoft/winappcli

A CLI está em preview pública. O repositório no GitHub tem a documentação completa e o anúncio original tem todos os detalhes.

Pare de ficar de olho no seu terminal: o modo desacoplado do Aspire muda o fluxo de trabalho

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Toda vez que você executa um AppHost do Aspire, seu terminal some. Travado. Ocupado até você pressionar Ctrl+C. Precisa rodar um comando rápido? Abra outra aba. Quer verificar os logs? Mais uma aba. É um pequeno atrito que se acumula rápido.

O Aspire 13.2 resolve isso. James Newton-King escreveu todos os detalhes, e sinceramente, essa é uma daquelas funcionalidades que muda imediatamente a forma como você trabalha.

Modo desacoplado: um comando, terminal de volta

aspire start

Esse é o atalho para aspire run --detach. Seu AppHost inicia em segundo plano e você recupera seu terminal imediatamente. Sem abas extras. Sem multiplexador de terminal. Apenas seu prompt, pronto para usar.

Gerenciando o que está rodando

A questão é — rodar em segundo plano só é útil se você conseguir gerenciar o que está lá fora. O Aspire 13.2 traz um conjunto completo de comandos CLI para exatamente isso:

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

Isso transforma o CLI do Aspire em um verdadeiro gerenciador de processos. Você pode iniciar múltiplos AppHosts, verificar seus status, acompanhar seus logs e encerrá-los — tudo a partir de uma única sessão de terminal.

Combine com o modo isolado

O modo desacoplado combina naturalmente com o modo isolado. Quer rodar duas instâncias do mesmo projeto em segundo plano sem conflitos de porta?

aspire start --isolated
aspire start --isolated

Cada uma recebe portas aleatórias, secrets separados e seu próprio ciclo de vida. Use aspire ps para ver ambas, aspire stop para encerrar a que você não precisa mais.

Por que isso é enorme para agentes de código

É aqui que fica realmente interessante. Um agente de código trabalhando no seu terminal agora pode:

Iniciar a app com aspire start
Consultar seu estado com aspire describe
Verificar logs com aspire logs para diagnosticar problemas
Parar com aspire stop quando terminar

Tudo sem perder a sessão do terminal. Antes do modo desacoplado, um agente que executasse seu AppHost ficava preso no próprio terminal. Agora ele pode iniciar, observar, iterar e limpar — exatamente como você gostaria que um agente autônomo funcionasse.

A equipe do Aspire investiu nisso. Executar aspire agent init configura um arquivo de habilidades do Aspire que ensina esses comandos aos agentes. Assim, ferramentas como o agente de código do Copilot podem gerenciar suas cargas de trabalho do Aspire diretamente.

Finalizando

O modo desacoplado é uma melhoria de fluxo de trabalho disfarçada de uma simples flag. Você para de alternar contexto entre terminais, agentes param de se bloquear, e os novos comandos CLI dão visibilidade real do que está rodando. É prático, é limpo, e torna o ciclo de desenvolvimento diário visivelmente mais fluido.

Leia o post completo para todos os detalhes e obtenha o Aspire 13.2 com aspire update --self.

Clustering de Pins Finalmente Chega ao .NET MAUI Maps — Uma Propriedade, Zero Dor de Cabeça

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

Sabe aquele momento quando você carrega um mapa com uma centena de pins e tudo vira uma mancha ilegível? É, essa tem sido a experiência com .NET MAUI Maps até agora. Acabou.

David Ortinau acabou de anunciar que o .NET MAUI 11 Preview 3 traz clustering de pins embutido no Android e iOS/Mac Catalyst. E a melhor parte — é ridiculamente simples de ativar.

Uma propriedade para governar todos

<maps:Map IsClusteringEnabled="True" />

É isso. Pins próximos são agrupados em clusters com um badge de contagem. Dá zoom e eles expandem. Afasta e eles colapsam. O tipo de comportamento que os usuários esperam de qualquer mapa moderno — e agora você consegue com uma única propriedade.

Grupos de clustering independentes

Aqui é onde fica interessante. Nem todos os pins devem se agrupar juntos. Cafeterias e parques são coisas diferentes, e seu mapa deveria saber disso.

A propriedade ClusteringIdentifier permite separar pins em grupos independentes:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Pins com o mesmo identificador se agrupam juntos. Identificadores diferentes formam clusters independentes mesmo quando estão geograficamente próximos. Sem identificador? Grupo padrão. Limpo e previsível.

Tratamento de taps em clusters

Quando um usuário toca em um cluster, você recebe um evento ClusterClicked com tudo que precisa:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

Os argumentos do evento te dão Pins (os pins no cluster), Location (o centro geográfico) e Handled (defina como true se quiser sobrescrever o zoom padrão). Simples, prático, exatamente o que você esperaria.

Detalhes de plataforma que vale a pena conhecer

No Android, o clustering usa um algoritmo personalizado baseado em grid que recalcula nas mudanças de zoom — sem dependências externas. No iOS e Mac Catalyst, ele aproveita o suporte nativo do MKClusterAnnotation do MapKit, o que significa animações suaves e nativas da plataforma.

Esse é um daqueles casos em que o time do MAUI tomou a decisão certa — apoiar-se na plataforma onde faz sentido.

Por que isso importa

Clustering de pins tem sido uma das funcionalidades mais solicitadas no .NET MAUI (issue #11811), e com razão. Toda app que mostra localizações em um mapa — rastreamento de entregas, localizadores de lojas, imobiliárias — precisa disso. Antes você tinha que construir por conta própria ou usar uma biblioteca de terceiros. Agora vem integrado.

Para nós desenvolvedores .NET construindo apps móveis multiplataforma, esse é o tipo de melhoria de qualidade de vida que faz do MAUI uma escolha genuinamente prática para cenários com uso intensivo de mapas.

Comece agora

Instale o .NET 11 Preview 3 e atualize o workload do .NET MAUI. O exemplo de Maps inclui uma nova página de Clustering com a qual você pode brincar imediatamente.

Vá construir algo com isso — e deixe seus mapas finalmente respirarem.

.NET Abril 2026 Servicing — Patches de segurança que você deve aplicar hoje

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

As atualizações de servicing de abril de 2026 para .NET e .NET Framework já estão disponíveis, e esta inclui correções de segurança que você vai querer aplicar logo. Seis CVEs corrigidos, incluindo duas vulnerabilidades de execução remota de código (RCE).

O que foi corrigido

Aqui vai o resumo rápido:

CVE	Tipo	Afeta
CVE-2026-26171	Bypass de recurso de segurança	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	Execução remota de código	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	Execução remota de código	.NET 10, 9, 8
CVE-2026-32203	Negação de serviço	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	Negação de serviço	.NET Framework 3.0–4.8.1
CVE-2026-32226	Negação de serviço	.NET Framework 2.0–4.8.1

Os dois CVEs de RCE (CVE-2026-32178 e CVE-2026-33116) afetam a maior gama de versões do .NET e devem ser a prioridade.

Versões atualizadas

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

Todas estão disponíveis pelos canais habituais — dotnet.microsoft.com, imagens de contêineres no MCR e gerenciadores de pacotes Linux.

O que fazer

Atualize seus projetos e pipelines de CI/CD para as últimas versões corrigidas. Se você está rodando contêineres, baixe as imagens mais recentes. Se está no .NET Framework, confira as notas de versão do .NET Framework para os patches correspondentes.

Para quem está rodando .NET 10 em produção (é a versão atual), 10.0.6 é uma atualização obrigatória. O mesmo vale para .NET 9.0.15 e .NET 8.0.26 se você está nessas versões LTS. Duas vulnerabilidades de RCE não são algo que se adia.

Azure MCP Server 2.0 Chegou — Automação Agnóstica em Nuvem Self-Hosted Está Aqui

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

Este artigo foi traduzido automaticamente. Para a versão original, clique aqui.

Se você vem construindo algo com MCP e Azure ultimamente, provavelmente já sabe que a experiência local funciona bem. Coloque um servidor MCP, deixe seu agente IA falar com recursos do Azure, siga em frente. Mas no momento em que você precisa compartilhar essa configuração com um time? É aí que as coisas ficavam complicadas.

Não mais. Azure MCP Server acabou de atingir a versão 2.0 estável, e a feature principal é exatamente o que times empresariais estão pedindo: suporte para servidor MCP remoto self-hosted.

O que é Azure MCP Server?

Um rápido refresco. Azure MCP Server implementa a especificação do Model Context Protocol e expõe capacidades do Azure como ferramentas estruturadas e descobríveis que agentes IA podem invocar. Pense nisto como uma ponte padronizada entre seu agente e o Azure — provisionamento, implantação, monitoramento, diagnósticos, tudo através de uma interface consistente.

Os números falam por si: 276 ferramentas MCP em 57 serviços do Azure. Isso é cobertura séria.

O grande destaque: implantações remotas self-hosted

Aqui está a questão. Executar MCP localmente na sua máquina é bom para dev e experimentos. Mas em um cenário real de time, você precisa de:

Acesso compartilhado para desenvolvedores e sistemas de agentes internos
Configuração centralizada (contexto de tenant, padrões de assinatura, telemetria)
Limites de rede e política empresariais
Integração em pipelines CI/CD

Azure MCP Server 2.0 aborda tudo isso. Você pode implantá-lo como um serviço interno gerenciado centralmente com transporte baseado em HTTP, autenticação apropriada e governança consistente.

Para autenticação, você tem duas opções sólidas:

Managed Identity — quando em execução junto com Microsoft Foundry
Fluxo On-Behalf-Of (OBO) — delegação OpenID Connect que chama APIs do Azure usando o contexto do usuário autenticado

Esse fluxo OBO é particularmente interessante para nós desenvolvedores .NET. Significa que seus fluxos de trabalho agnósticos podem operar com as permissões reais do usuário, não alguma conta de serviço com privilégios excessivos. Princípio do menor privilégio, embutido certo.

Endurecimento de segurança

Isso não é apenas um lançamento de feature — é um de segurança também. O lançamento 2.0 adiciona:

Validação de endpoint mais forte
Proteções contra padrões de injeção em ferramentas orientadas a query
Controles de isolamento mais rigorosos para ambientes de dev

Se você vai expor MCP como um serviço compartilhado, essas salvaguardas importam. Muito.

Onde você pode usá-lo?

A história de compatibilidade do cliente é ampla. Azure MCP Server 2.0 funciona com:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
Agentes CLI: GitHub Copilot CLI, Claude Code
Standalone: servidor local para configurações simples
Self-hosted remoto: a nova estrela do 2.0

Além disso há suporte a nuvem soberana para Azure US Government e Azure operado pela 21Vianet, que é crítico para implantações reguladas.

Por que isso importa para desenvolvedores .NET

Se você está construindo aplicações agnósticas com .NET — seja com Semantic Kernel, Microsoft Agent Framework, ou sua própria orquestração — Azure MCP Server 2.0 lhe dá uma maneira pronta para produção de deixar seus agentes interagirem com infraestrutura do Azure. Sem wrappers REST customizados. Sem padrões de integração específicos do serviço. Apenas MCP.

Combinado com a API fluente para MCP Apps que saiu alguns dias atrás, o ecossistema MCP .NET está amadurecendo rapidamente.

Começando

Escolha seu caminho:

Repositório GitHub — código fonte, documentação, tudo
Imagem Docker — implantação containerizada
Extensão VS Code — integração de IDE
Guia de self-hosting — a feature principal do 2.0

Resumindo

Azure MCP Server 2.0 é exatamente o tipo de upgrade de infraestrutura que não parece vistoso em uma demo mas muda tudo na prática. MCP remoto self-hosted com autenticação apropriada, endurecimento de segurança e suporte a nuvem soberana significa que MCP está pronto para times reais construindo fluxos de trabalho agnósticos reais no Azure. Se você estava esperando o sinal “pronto para empresas” — esse é ele.

.NET Aspire 13.2 Quer Ser o Melhor Amigo do Seu Agente de IA

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Sabe aquele momento quando seu agente de IA escreve um código sólido, você fica empolgado, e aí tudo desmorona quando ele tenta executar a coisa? Conflitos de porta, processos fantasma, variáveis de ambiente erradas — de repente seu agente está queimando tokens fazendo troubleshooting de problemas de inicialização em vez de construir funcionalidades.

O time do Aspire acabou de publicar um post muito bem pensado sobre exatamente esse problema, e a resposta deles é convincente: Aspire 13.2 foi projetado não apenas para humanos, mas para agentes de IA.

O problema é real

Agentes de IA são incríveis escrevendo código. Mas entregar uma app full-stack funcional envolve muito mais do que gerar arquivos. Você precisa iniciar serviços na ordem certa, gerenciar portas, configurar variáveis de ambiente, conectar bancos de dados e obter feedback quando as coisas quebram. Agora, a maioria dos agentes lida com tudo isso por tentativa e erro — executando comandos, lendo saída de erros, tentando de novo.

Nós empilhamos instruções Markdown, skills personalizados e prompts para guiá-los, mas são imprevisíveis, não podem ser compilados e custam tokens só para fazer parse. O time do Aspire acertou no insight central: agentes precisam de compiladores e APIs estruturadas, não mais Markdown.

Aspire como infraestrutura para agentes

Eis o que o Aspire 13.2 traz para a mesa do desenvolvimento agêntico:

Toda a sua stack em código tipado. O AppHost define toda sua topologia — API, frontend, banco de dados, cache — em TypeScript ou C# compilável:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Um agente pode ler isso para entender a topologia da app, adicionar recursos, conectar componentes e compilar para verificar. O compilador diz imediatamente se algo está errado. Sem adivinhação, sem tentativa e erro com arquivos de configuração.

Um comando para governar todos. Em vez de agentes malabarizando docker compose up, npm run dev e scripts de inicialização de banco de dados, tudo é simplesmente aspire start. Todos os recursos são lançados na ordem certa, nas portas certas, com a configuração certa. Processos de longa duração também não travam o agente — o Aspire os gerencia.

Modo isolado para agentes paralelos. Com --isolated, cada execução do Aspire recebe suas próprias portas aleatórias e segredos de usuário separados. Tem múltiplos agentes trabalhando em git worktrees? Eles não vão colidir. Isso é enorme para ferramentas como os agentes em segundo plano do VS Code que criam ambientes paralelos.

Olhos de agente através de telemetria. Aqui é onde fica realmente poderoso. A CLI do Aspire expõe dados OpenTelemetry completos durante o desenvolvimento — traces, métricas, logs estruturados. Seu agente não está apenas lendo saída de console e torcendo pelo melhor. Ele pode rastrear uma requisição falhada entre serviços, perfilar endpoints lentos e identificar exatamente onde as coisas quebram. Isso é observabilidade de nível produção no ciclo de desenvolvimento.

A analogia dos para-choques de boliche

O time do Aspire usa uma ótima analogia: pense no Aspire como os para-choques de pista de boliche para agentes de IA. Se o agente não for perfeito (e não será), os para-choques evitam que ele jogue na canaleta. A definição do stack previne erros de configuração, o compilador captura erros, a CLI gerencia processos e a telemetria fornece o ciclo de feedback.

Combine isso com algo como Playwright CLI, e seu agente pode realmente usar sua app — clicando nos fluxos, checando o DOM, vendo coisas quebradas na telemetria, consertando o código, reiniciando e testando de novo. Construir, executar, observar, consertar. Esse é o ciclo de desenvolvimento autônomo que estávamos perseguindo.

Primeiros passos

Novo no Aspire? Instale a CLI em get.aspire.dev e siga o guia de início.

Já usa Aspire? Execute aspire update --self para obter a 13.2, depois aponte seu agente de código favorito para seu repo. Você pode se surpreender com o quanto mais longe ele chega com os guardrails do Aspire.

Concluindo

Aspire 13.2 não é mais apenas um framework para apps distribuídas — está se tornando infraestrutura essencial para agentes. Definições de stack estruturadas, inicialização com um comando, execuções paralelas isoladas e telemetria em tempo real dão aos agentes de IA exatamente o que precisam para ir de escrever código a entregar apps.

Leia o post completo do time do Aspire para todos os detalhes e vídeos de demonstração.

A avaliação de modernização do GitHub Copilot é a melhor ferramenta de migração que você ainda não está usando

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Migrar uma aplicação legada do .NET Framework para .NET moderno é uma daquelas tarefas que todo mundo sabe que deveria fazer, mas ninguém quer começar. Nunca é apenas “mudar o target framework.” São APIs que desapareceram, pacotes que não existem mais, modelos de hosting que funcionam de forma completamente diferente, e um milhão de pequenas decisões sobre o que containerizar, o que reescrever e o que deixar como está.

Jeffrey Fritz acabou de publicar um mergulho profundo na avaliação de modernização do GitHub Copilot, e honestamente? Este é o melhor tooling de migração que eu vi para .NET. Não pela geração de código — isso já é padrão agora. Pelo documento de avaliação que ele produz.

Não é apenas um motor de sugestões de código

A extensão do VS Code segue um modelo de Avaliar → Planejar → Executar. A fase de avaliação analisa todo o seu codebase e produz um documento estruturado que captura tudo: o que precisa mudar, quais recursos Azure provisionar, qual modelo de deploy usar. Tudo que vem depois — infraestrutura como código, containerização, manifestos de deploy — flui do que a avaliação encontra.

A avaliação é armazenada em .github/modernize/assessment/ no seu projeto. Cada execução produz um relatório independente, então você vai construindo um histórico e pode acompanhar como sua postura de migração evolui conforme corrige issues.

Duas formas de começar

Avaliação Recomendada — o caminho rápido. Escolha entre domínios curados (Upgrade Java/.NET, Cloud Readiness, Segurança) e obtenha resultados significativos sem mexer em configuração. Ótimo para um primeiro olhar de onde sua aplicação está.

Avaliação Personalizada — o caminho direcionado. Configure exatamente o que analisar: compute alvo (App Service, AKS, Container Apps), SO alvo, análise de containerização. Escolha múltiplos alvos Azure para comparar abordagens de migração lado a lado.

Essa visão de comparação é genuinamente útil. Uma app com 3 issues obrigatórios para App Service pode ter 7 para AKS. Ver ambos ajuda a tomar a decisão de hosting antes de se comprometer com um caminho de migração.

O detalhamento de issues é acionável

Cada issue vem com um nível de criticidade:

Obrigatório — deve ser corrigido ou a migração falha
Potencial — pode impactar a migração, precisa de julgamento humano
Opcional — melhorias recomendadas, não bloqueiam a migração

E cada issue linka para arquivos afetados e números de linha, fornece uma descrição detalhada do que está errado e por que importa para sua plataforma alvo, dá passos concretos de remediação (não apenas “corrija isso”), e inclui links para documentação oficial.

Você pode atribuir issues individuais a desenvolvedores e eles têm tudo que precisam para agir. Essa é a diferença entre uma ferramenta que diz “tem um problema” e uma que diz como resolver.

Os caminhos de upgrade cobertos

Para .NET especificamente:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Cada caminho de upgrade tem regras de detecção que sabem quais APIs foram removidas, quais padrões não têm equivalente direto, e quais issues de segurança precisam de atenção.

Para times que gerenciam múltiplas aplicações, também há um CLI que suporta avaliações batch multi-repo — clone todos os repos, avalie todos, obtenha relatórios por app mais uma visão agregada do portfólio.

Minha opinião

Se você está sentado em cima de aplicações legadas em .NET Framework (e vamos ser honestos, a maioria dos times enterprise está), esta é a ferramenta para começar. Só o documento de avaliação já vale o tempo — transforma um vago “deveríamos modernizar” em uma lista concreta e priorizada de itens de trabalho com caminhos claros adiante.

O fluxo de trabalho colaborativo também é inteligente: exporte avaliações, compartilhe com seu time, importe-as sem re-executar. Revisões de arquitetura onde quem toma decisões não é quem roda as ferramentas? Coberto.

Finalizando

A avaliação de modernização do GitHub Copilot transforma a migração .NET de um projeto assustador e indefinido em um processo estruturado e rastreável. Comece com uma avaliação recomendada para ver onde você está, depois use avaliações personalizadas para comparar alvos Azure e construir seu plano de migração.

Leia o walkthrough completo e baixe a extensão do VS Code para testar no seu próprio codebase.

Conecte seus servidores MCP no Azure Functions aos Foundry Agents — Veja como

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Isso é algo que eu amo no ecossistema MCP: você constrói seu servidor uma vez e ele funciona em qualquer lugar. VS Code, Visual Studio, Cursor, ChatGPT — cada cliente MCP pode descobrir e usar suas ferramentas. Agora, a Microsoft está adicionando mais um consumidor a essa lista: os agentes Foundry.

Lily Ma da equipe do Azure SDK publicou um guia prático sobre como conectar servidores MCP implantados no Azure Functions com agentes Microsoft Foundry. Se você já tem um servidor MCP, isso é puro valor agregado — sem necessidade de reconstruir nada.

Por que essa combinação faz sentido

Azure Functions te dá infraestrutura escalável, autenticação integrada e cobrança serverless para hospedar servidores MCP. Microsoft Foundry te dá agentes de IA que podem raciocinar, planejar e agir. Conectar os dois significa que suas ferramentas personalizadas — consultar um banco de dados, chamar uma API de negócio, executar lógica de validação — se tornam capacidades que agentes de IA empresariais podem descobrir e usar autonomamente.

O ponto-chave: seu servidor MCP continua o mesmo. Você está apenas adicionando o Foundry como mais um consumidor. As mesmas ferramentas que funcionam no seu setup do VS Code agora alimentam um agente de IA com o qual sua equipe ou clientes interagem.

Opções de autenticação

É aqui que o post realmente agrega valor. Quatro métodos de autenticação dependendo do seu cenário:

Método	Caso de uso
Baseado em chave (padrão)	Desenvolvimento ou servidores sem autenticação Entra
Microsoft Entra	Produção com identidades gerenciadas
Passthrough de identidade OAuth	Produção onde cada usuário se autentica individualmente
Sem autenticação	Dev/testes ou apenas dados públicos

Para produção, Microsoft Entra com identidade do agente é o caminho recomendado. O passthrough de identidade OAuth é para quando o contexto do usuário importa — o agente solicita que os usuários façam login, e cada requisição carrega o token próprio do usuário.

Configurando

O fluxo geral:

Faça deploy do seu servidor MCP no Azure Functions — exemplos disponíveis para .NET, Python, TypeScript e Java
Habilite a autenticação MCP integrada na sua function app
Obtenha sua URL de endpoint — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Adicione o servidor MCP como ferramenta no Foundry — navegue até seu agente no portal, adicione uma nova ferramenta MCP, forneça o endpoint e as credenciais

Depois teste no playground do Agent Builder enviando um prompt que acionaria uma das suas ferramentas.

Minha opinião

A história de composabilidade aqui está ficando realmente forte. Construa seu servidor MCP uma vez em .NET (ou Python, TypeScript, Java), faça deploy no Azure Functions, e cada cliente compatível com MCP pode usá-lo — ferramentas de programação, apps de chat, e agora agentes de IA empresariais. É um padrão “escreva uma vez, use em qualquer lugar” que realmente funciona.

Para desenvolvedores .NET especificamente, a extensão MCP do Azure Functions torna isso simples. Você define suas ferramentas como Azure Functions, faz deploy, e tem um servidor MCP de nível de produção com toda a segurança e escalabilidade que o Azure Functions proporciona.

Finalizando

Se você tem ferramentas MCP rodando no Azure Functions, conectá-las aos agentes Foundry é uma vitória rápida — suas ferramentas personalizadas se tornam capacidades de IA empresarial com autenticação adequada e sem alterações de código no servidor.

Leia o guia completo para instruções passo a passo sobre cada método de autenticação, e confira a documentação detalhada para configurações de produção.

MCP Apps ganham uma API fluente — Construa interfaces ricas para ferramentas de IA em .NET em três passos

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Ferramentas MCP são ótimas para dar capacidades aos agentes de IA. Mas e se a sua ferramenta precisa mostrar algo ao usuário — um dashboard, um formulário, uma visualização interativa? É aí que entram as MCP Apps, e elas ficaram muito mais fáceis de construir.

Lilian Kasem da equipe do Azure SDK apresentou a nova API de configuração fluente para MCP Apps no Azure Functions com .NET, e é o tipo de melhoria na experiência do desenvolvedor que faz a gente se perguntar por que não era sempre assim tão simples.

O que são MCP Apps?

MCP Apps estendem o Model Context Protocol permitindo que as ferramentas carreguem suas próprias views de UI, assets estáticos e controles de segurança. Em vez de apenas retornar texto, sua ferramenta MCP pode renderizar experiências HTML completas — dashboards interativos, visualizações de dados, formulários de configuração — tudo invocável por agentes de IA e apresentado aos usuários pelos clientes MCP.

O problema era que conectar tudo isso manualmente exigia conhecer a especificação MCP a fundo: URIs ui://, tipos MIME especiais, coordenação de metadados entre ferramentas e recursos. Não era difícil, mas trabalhoso.

A API fluente em três passos

Passo 1: Defina sua função. Uma ferramenta MCP padrão do Azure Functions:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Passo 2: Promova-a a MCP App. No startup do seu programa:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Passo 3: Adicione sua view HTML. Crie assets/hello-app.html com a interface que você precisa.

É isso. A API fluente cuida de toda a encanação do protocolo MCP — gera a função de recurso sintético, define o tipo MIME correto e injeta os metadados que conectam sua ferramenta à sua view.

A superfície da API é bem projetada

Algumas coisas que eu realmente gosto:

As fontes de views são flexíveis. Você pode servir HTML a partir de arquivos no disco, ou embutir recursos diretamente no seu assembly para deploys independentes:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

O CSP é componível. Você permite explicitamente as origens que sua app precisa, seguindo princípios de menor privilégio. Chame WithCsp várias vezes e as origens se acumulam:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Controle de visibilidade. Você pode tornar uma ferramenta visível apenas para o LLM, apenas para a UI do host, ou ambos. Quer uma ferramenta que só renderiza UI e não deve ser chamada pelo modelo? Fácil:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Primeiros passos

Adicione o pacote preview:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Se você já está construindo ferramentas MCP com Azure Functions, isso é apenas uma atualização de pacote. O quickstart de MCP Apps é o melhor lugar para começar se você é novo no conceito.

Finalizando

MCP Apps são um dos desenvolvimentos mais empolgantes no espaço de ferramentas de IA — ferramentas que não apenas fazem coisas, mas podem mostrar coisas aos usuários. A API fluente remove a complexidade do protocolo e permite que você se concentre no que importa: a lógica da sua ferramenta e sua interface.

Leia o post completo para a referência completa da API e exemplos.

O Modo Isolado do Aspire Resolve o Pesadelo de Conflitos de Porta no Desenvolvimento Paralelo

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Se você já tentou executar duas instâncias do mesmo projeto ao mesmo tempo, conhece a dor. A porta 8080 já está em uso. A porta 17370 está ocupada. Matar algo, reiniciar, fazer malabarismo com variáveis de ambiente — é um assassino de produtividade.

Esse problema está piorando, não melhorando. Agentes de IA criam git worktrees para trabalhar de forma independente. Agentes em segundo plano criam ambientes separados. Desenvolvedores fazem checkout do mesmo repo duas vezes para branches de funcionalidades. Cada um desses cenários bate na mesma parede: duas instâncias da mesma app brigando pelas mesmas portas.

Aspire 13.2 resolve isso com um único flag. James Newton-King do time do Aspire escreveu todos os detalhes, e é uma daquelas funcionalidades “por que não tínhamos isso antes?”

A solução: `--isolated`

aspire run --isolated

Isso é tudo. Cada execução recebe:

Portas aleatórias — sem mais colisões entre instâncias
Segredos de usuário isolados — connection strings e chaves API ficam separadas por instância

Sem reatribuição manual de portas. Sem malabarismo de variáveis de ambiente. Cada execução recebe um ambiente limpo e livre de colisões automaticamente.

Cenários reais onde isso brilha

Múltiplos checkouts. Você tem uma branch de funcionalidade em um diretório e um bugfix em outro:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Ambos rodam sem conflitos. O dashboard mostra o que está rodando e onde.

Agentes em segundo plano no VS Code. Quando o agente em background do Copilot Chat cria um git worktree para trabalhar no seu código de forma independente, ele pode precisar executar seu AppHost do Aspire. Sem --isolated, isso é uma colisão de porta com seu worktree principal. Com ele, ambas instâncias simplesmente funcionam.

O skill do Aspire que vem com aspire agent init instrui automaticamente os agentes a usar --isolated quando trabalhando em worktrees. Então o agente em background do Copilot deve lidar com isso nativamente.

Testes de integração junto ao desenvolvimento. Precisa rodar testes contra um AppHost ao vivo enquanto continua construindo funcionalidades? O modo isolado dá a cada contexto suas próprias portas e configuração.

Como funciona internamente

Quando você passa --isolated, a CLI gera um ID de instância único para a execução. Isso aciona dois comportamentos:

Randomização de portas — em vez de vincular a portas previsíveis definidas na configuração do seu AppHost, o modo isolado escolhe portas aleatórias disponíveis para tudo — o dashboard, endpoints de serviço, tudo. O service discovery se ajusta automaticamente, então os serviços se encontram independentemente de quais portas foram atribuídas.
Isolamento de segredos — cada execução isolada recebe seu próprio armazenamento de user secrets, indexado pelo ID da instância. Connection strings e chaves API de uma execução não vazam para outra.

Seu código não precisa de mudanças. O service discovery do Aspire resolve endpoints em tempo de execução, então tudo se conecta corretamente independentemente da atribuição de portas.

Quando usar

Use --isolated quando executar múltiplas instâncias do mesmo AppHost simultaneamente — seja desenvolvimento paralelo, testes automatizados, agentes de IA ou git worktrees. Para desenvolvimento de instância única onde você prefere portas previsíveis, o aspire run regular continua funcionando bem.

Concluindo

O modo isolado é uma funcionalidade pequena que resolve um problema real e cada vez mais comum. À medida que o desenvolvimento assistido por IA nos empurra para mais fluxos paralelos — múltiplos agentes, múltiplos worktrees, múltiplos contextos — a capacidade de simplesmente subir outra instância sem brigar por portas é essencial.

Leia o post completo para todos os detalhes técnicos e experimente com aspire update --self para obter a 13.2.

C# 15 ganha Union Types — e são exatamente o que estávamos pedindo

Emiliano Montesdeoca — Sun, 05 Apr 2026 00:00:00 +0000

Essa é a que eu estava esperando. C# 15 introduz a palavra-chave union — uniões discriminadas de verdade com pattern matching exaustivo imposto pelo compilador. Se você já invejou as uniões discriminadas do F# ou os enums do Rust, sabe exatamente por que isso importa.

Bill Wagner publicou a análise detalhada no blog do .NET, e sinceramente? O design é limpo, prático e muito C#. Deixa eu te mostrar o que realmente tem aqui e por que é mais importante do que parece à primeira vista.

O problema que as uniões resolvem

Antes do C# 15, retornar “um dentre vários tipos possíveis” de um método era sempre um compromisso:

object — sem restrições, sem ajuda do compilador, casting defensivo por toda parte
Interfaces marcadoras — melhor, mas qualquer um pode implementá-las. O compilador nunca pode considerar o conjunto completo
Classes base abstratas — mesmo problema, além dos tipos precisarem de um ancestral comum

Nenhuma dessas opções te dá o que você realmente quer: um conjunto fechado de tipos onde o compilador garante que você tratou todos os casos. É isso que os tipos union fazem.

A sintaxe é lindamente simples

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Uma linha. Pet pode conter um Cat, um Dog ou um Bird. Conversões implícitas são geradas automaticamente:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

E aqui está a mágica — o compilador impõe o matching exaustivo:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

Sem necessidade de discard _. O compilador sabe que esse switch cobre todos os casos possíveis. Se você depois adicionar um quarto tipo à union, cada expressão switch que não o trata produz um aviso. Casos faltantes detectados no tempo de compilação, não em tempo de execução.

Onde isso se torna prático

O exemplo do Pet é bonitinho, mas é aqui que as uniões realmente brilham em código real.

Respostas de API que retornam formas diferentes

public union ApiResult<T>(T, ApiError, ValidationFailure);

Agora todo consumidor é obrigado a tratar sucesso, erro e falha de validação. Chega de bugs de “esqueci de verificar o caso de erro”.

Valor único ou coleção

O padrão OneOrMore<T> mostra como as uniões podem ter um corpo com métodos auxiliares:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Os chamadores passam a forma que for mais conveniente:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

Compor tipos não relacionados

Essa é a funcionalidade matadora em relação às hierarquias tradicionais. Você pode unir tipos que não têm nada em comum — string e Exception, int e IEnumerable<T>. Sem necessidade de ancestral comum.

Uniões personalizadas para bibliotecas existentes

Aqui vai uma decisão de design inteligente: qualquer classe ou struct com um atributo [Union] é reconhecida como um tipo union, desde que siga o padrão básico (construtores públicos para os tipos de caso e uma propriedade Value). Bibliotecas como OneOf que já fornecem tipos similares a uniões podem optar pelo suporte do compilador sem reescrever seus internos.

Para cenários sensíveis a performance com tipos de valor, bibliotecas podem implementar um padrão de acesso sem boxing com os métodos HasValue e TryGetValue.

O panorama geral

Os tipos union fazem parte de uma história mais ampla de exaustividade chegando ao C#:

Tipos union — matching exaustivo sobre um conjunto fechado de tipos (disponível agora em preview)
Hierarquias fechadas — o modificador closed impede classes derivadas fora do assembly de definição (proposto)
Enums fechados — impede a criação de valores além dos membros declarados (proposto)

Juntas, essas três funcionalidades darão ao C# um dos sistemas de pattern matching type-safe mais completos em qualquer linguagem mainstream.

Experimente hoje

Os tipos union estão disponíveis no .NET 11 Preview 2:

Instale o SDK .NET 11 Preview
Aponte para net11.0 no seu projeto
Configure <LangVersion>preview</LangVersion>

Um detalhe: no Preview 2, você vai precisar declarar UnionAttribute e IUnion no seu projeto já que eles ainda não estão no runtime. Pegue o RuntimePolyfill.cs do repo de docs, ou adicione isso:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Fechando

Os tipos union são uma daquelas funcionalidades que fazem você se perguntar como sobrevivemos sem elas. Pattern matching exaustivo imposto pelo compilador, sintaxe limpa, suporte a generics e integração com o pattern matching existente — é tudo que pedimos, feito do jeito C#.

Experimente no .NET 11 Preview 2, quebre coisas e compartilhe seu feedback no GitHub. Isso é preview, e o time de C# está ouvindo ativamente. Seus edge cases e feedback de design vão moldar a versão final.

Para a referência completa da linguagem, confira a documentação de tipos union e a especificação da funcionalidade.

Aspire 13.2 traz uma CLI de documentação — e seu agente de IA também pode usá-la

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

Você conhece aquele momento quando está mergulhado num Aspire AppHost, conectando integrações, e precisa verificar exatamente quais parâmetros a integração Redis espera? Você faz alt-tab pro navegador, procura pelo aspire.dev, aperta os olhos nos docs da API, e volta pro seu editor. Contexto perdido. Flow quebrado.

Aspire 13.2 acabou de lançar uma solução pra isso. A CLI aspire docs permite que você pesquise, navegue e leia documentação oficial do Aspire diretamente do seu terminal. E como é respaldada por serviços reutilizáveis, agentes de IA e skills podem usar os mesmos comandos para consultar docs em vez de alucinar APIs que não existem.

O problema que isso realmente resolve

David Pine acerta em cheio no post original: agentes de IA eram terríveis em ajudar desenvolvedores a construir apps com Aspire. Recomendavam dotnet run em vez de aspire run, referenciavam learn.microsoft.com para docs que vivem no aspire.dev, sugeriam pacotes NuGet desatualizados, e — meu favorito pessoal — alucinavam APIs que não existem.

Por quê? Porque Aspire foi específico de .NET por muito mais tempo do que é poliglota, e os LLMs trabalham com dados de treinamento que antecedem os recursos mais recentes. Quando você dá a um agente de IA a capacidade de consultar os docs atuais, ele para de adivinhar e começa a ser útil.

Três comandos, zero abas do navegador

A CLI é refrescantemente simples:

Listar todos os docs

aspire docs list

Retorna cada página de documentação disponível no aspire.dev. Precisa de saída legível por máquina? Adicione --format Json.

Pesquisar um tópico

aspire docs search "redis"

Pesquisa tanto em títulos quanto em conteúdo com pontuação de relevância ponderada. O mesmo motor de busca que alimenta a ferramenta de documentação internamente. Você obtém resultados ranqueados com títulos, slugs e scores de relevância.

Ler uma página inteira (ou apenas uma seção)

aspire docs get redis-integration

Transmite a página completa como markdown pro seu terminal. Precisa de apenas uma seção?

aspire docs get redis-integration --section "Add Redis resource"

Precisão cirúrgica. Sem rolar por 500 linhas. Só a parte que você precisa.

O ângulo do agente de IA

Aqui é onde fica interessante pra nós desenvolvedores que construímos com ferramentas de IA. Os mesmos comandos aspire docs funcionam como ferramentas para agentes de IA — através de skills, servidores MCP, ou wrappers simples de CLI.

Em vez do seu assistente de IA inventar APIs do Aspire baseadas em dados de treinamento desatualizados, ele pode chamar aspire docs search "postgres", encontrar os docs oficiais de integração, ler a página certa, e te dar a abordagem documentada. Documentação em tempo real e atualizada — não o que o modelo memorizou seis meses atrás.

A arquitetura por trás disso é intencional. O time do Aspire construiu serviços reutilizáveis (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) em vez de uma integração pontual. Isso significa que o mesmo motor de busca funciona para humanos no terminal, agentes de IA no seu editor, e automação no seu pipeline de CI.

Cenários do mundo real

Consultas rápidas no terminal: Você está três arquivos de profundidade e precisa dos parâmetros de configuração do Redis. Dois comandos, noventa segundos, de volta ao trabalho:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Desenvolvimento assistido por IA: Seu skill do VS Code encapsula os comandos da CLI. Você pergunta “Adicione um banco de dados PostgreSQL ao meu AppHost” e o agente consulta os docs reais antes de responder. Sem alucinações.

Validação CI/CD: Seu pipeline valida configurações de AppHost contra documentação oficial programaticamente. A saída --format Json conecta-se limpo com jq e outras ferramentas.

Bases de conhecimento personalizadas: Construindo suas próprias ferramentas de IA? Envie a saída JSON estruturada direto pra sua base de conhecimento:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Sem web scraping. Sem chaves de API. Os mesmos dados estruturados que a ferramenta de documentação usa internamente.

A documentação está sempre atualizada

Esta é a parte que mais aprecio. A CLI não baixa um snapshot — ela consulta o aspire.dev com cache baseado em ETag. No momento em que os docs são atualizados, sua CLI e qualquer skill construído sobre ela reflete isso. Sem cópias desatualizadas, sem momentos de “mas o wiki dizia…”.

Pra fechar

aspire docs é uma daquelas funcionalidades pequenas que resolve um problema real de forma limpa. Humanos ganham acesso à documentação direto no terminal. Agentes de IA ganham uma forma de parar de adivinhar e começar a referenciar docs reais. E tudo é sustentado pela mesma fonte de verdade.

Se você está construindo com .NET Aspire e ainda não experimentou a CLI, execute aspire docs search "seu-topico-aqui" e veja como é. Depois considere envolver esses comandos em qualquer skill de IA ou configuração de automação que está usando — seus agentes vão agradecer.

Confira o mergulho profundo de David Pine sobre como a ferramenta de documentação foi construída, e a referência oficial da CLI para todos os detalhes.

Microsoft Agent Framework Chega à 1.0 — Eis O Que Realmente Importa para Desenvolvedores .NET

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

Se você tem acompanhado a jornada do Agent Framework desde os primeiros dias do Semantic Kernel e AutoGen, este é significativo. O Microsoft Agent Framework acabou de chegar à versão 1.0 — pronto para produção, APIs estáveis, compromisso de suporte de longo prazo. Está disponível tanto para .NET quanto para Python, e está genuinamente pronto para cargas de trabalho reais.

Vou cortar o ruído do anúncio e focar no que importa se você está construindo apps com IA usando .NET.

A versão curta

Agent Framework 1.0 unifica o que costumava ser Semantic Kernel e AutoGen em um único SDK open source. Uma abstração de agente. Um motor de orquestração. Múltiplos provedores de IA. Se você estava alternando entre Semantic Kernel para padrões enterprise e AutoGen para workflows multi-agente de nível pesquisa, pode parar. Este é o único SDK agora.

Começar é quase injustamente simples

Aqui está um agente funcional em .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

É isso. Um punhado de linhas e você tem um agente de IA rodando contra o Azure Foundry. O equivalente em Python é igualmente conciso. Adicione ferramentas de funções, conversas multi-turno e streaming conforme avança — a superfície da API escala sem ficar estranha.

Orquestração multi-agente — isso é pra valer

Agentes individuais são bons para demos, mas cenários de produção geralmente precisam de coordenação. Agent Framework 1.0 vem com padrões de orquestração testados em batalha diretamente da Microsoft Research e AutoGen:

Sequencial — agentes processam em ordem (escritor → revisor → editor)
Concorrente — distribui para múltiplos agentes em paralelo, converge resultados
Handoff — um agente delega para outro baseado na intenção
Chat em grupo — múltiplos agentes discutem e convergem para uma solução
Magentic-One — o padrão multi-agente de nível pesquisa do MSR

Todos suportam streaming, checkpointing, aprovações com humano no loop, e pausa/retomada. A parte de checkpointing é crucial — workflows de longa duração sobrevivem a reinícios de processo. Para nós desenvolvedores .NET que construímos workflows duráveis com Azure Functions, isso é familiar.

As funcionalidades que mais importam

Aqui está minha lista do que vale a pena saber:

Hooks de middleware. Sabe como o ASP.NET Core tem pipelines de middleware? Mesmo conceito, mas para execução de agentes. Intercepte cada estágio — adicione segurança de conteúdo, logging, políticas de compliance — sem tocar nos prompts do agente. É assim que você torna agentes prontos para enterprise.

Memória plugável. Histórico conversacional, estado persistente chave-valor, recuperação baseada em vetores. Escolha seu backend: Foundry Agent Service, Mem0, Redis, Neo4j, ou crie o seu próprio. Memória é o que transforma uma chamada LLM sem estado em um agente que realmente lembra do contexto.

Agentes YAML declarativos. Defina as instruções do seu agente, ferramentas, memória e topologia de orquestração em arquivos YAML versionados. Carregue e execute com uma única chamada de API. Isso é um divisor de águas para equipes que querem iterar no comportamento do agente sem reimplantar código.

Suporte A2A e MCP. MCP (Model Context Protocol) permite que agentes descubram e invoquem ferramentas externas dinamicamente. A2A (protocolo Agent-to-Agent) habilita colaboração entre runtimes — seus agentes .NET podem se coordenar com agentes rodando em outros frameworks. O suporte ao A2A 1.0 está chegando em breve.

As funcionalidades em preview que valem acompanhar

Algumas funcionalidades foram lançadas como preview na 1.0 — funcionais mas as APIs podem evoluir:

DevUI — um depurador local baseado em navegador para visualizar a execução do agente, fluxos de mensagens e chamadas de ferramentas em tempo real. Pense no Application Insights, mas para o raciocínio do agente.
GitHub Copilot SDK e Claude Code SDK — use o Copilot ou Claude como harness de agente diretamente do seu código de orquestração. Componha um agente capaz de programar ao lado dos seus outros agentes no mesmo workflow.
Agent Harness — um runtime local customizável que dá aos agentes acesso a shell, sistema de arquivos e loops de mensagens. Pense em agentes de código e padrões de automação.
Skills — pacotes reutilizáveis de capacidades de domínio que dão aos agentes capacidades estruturadas prontas para uso.

Migrando do Semantic Kernel ou AutoGen

Se você tem código existente de Semantic Kernel ou AutoGen, existem assistentes de migração dedicados que analisam seu código e geram planos de migração passo a passo. O guia de migração do Semantic Kernel e o guia de migração do AutoGen te guiam por tudo.

Se você estava nos pacotes RC, atualizar para 1.0 é apenas uma mudança de versão.

Finalizando

Agent Framework 1.0 é o marco de produção que as equipes enterprise estavam esperando. APIs estáveis, suporte multi-provedor, padrões de orquestração que realmente funcionam em escala, e caminhos de migração tanto do Semantic Kernel quanto do AutoGen.

O framework é totalmente open source no GitHub, e você pode começar hoje com dotnet add package Microsoft.Agents.AI. Confira o guia de início rápido e os exemplos para colocar a mão na massa.

Se você estava esperando o sinal de “seguro para usar em produção” — é este.

Atualização de março do Visual Studio permite criar agentes Copilot personalizados — e o find_symbol é revolucionário

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

O Visual Studio acabou de receber sua atualização Copilot mais significativa. Mark Downie anunciou a versão de março, e o destaque são os agentes personalizados — mas honestamente, a ferramenta find_symbol pode ser a que mais muda seu workflow.

Agentes Copilot personalizados no seu repo

Quer que o Copilot siga os padrões de código do seu time? Agentes personalizados são definidos como arquivos .agent.md em .github/agents/. Cada agente tem acesso completo ao workspace, compreensão de código, ferramentas, seu modelo preferido e conexões MCP.

Agent skills: pacotes de instruções reutilizáveis

Skills são carregados automaticamente de .github/skills/ no seu repo ou ~/.copilot/skills/ no seu perfil.

find_symbol: navegação com reconhecimento de linguagem

A nova ferramenta find_symbol dá ao modo agente do Copilot navegação de símbolos baseada em serviços de linguagem. Em vez de buscar texto, o agente pode encontrar todas as referências de um símbolo e acessar informações de tipo e escopo.

Para desenvolvedores .NET, é uma melhoria enorme — bases de código C# com hierarquias de tipos profundas se beneficiam enormemente.

Perfilar testes com Copilot

Há um novo Profile with Copilot no menu de contexto do Test Explorer. O Profiling Agent executa o teste e analisa performance automaticamente.

Perf tips durante debugging ao vivo

A otimização de performance agora acontece durante o debug. O Visual Studio mostra tempo de execução inline. Linha lenta? Clique no Perf Tip e peça sugestões ao Copilot.

Corrigir vulnerabilidades NuGet do Solution Explorer

Um link Fix with GitHub Copilot aparece diretamente no Solution Explorer quando uma vulnerabilidade é detectada.

Conclusão

Agentes personalizados e skills são o destaque, mas find_symbol é a joia escondida — muda fundamentalmente a precisão do Copilot ao refatorar código .NET. Baixe o Visual Studio 2026 Insiders para experimentar.

azd agora permite executar e depurar agentes IA localmente — O que mudou em março 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Sete versões em um mês. Foi isso que o time do Azure Developer CLI (azd) publicou em março 2026, e a funcionalidade principal é a que eu estava esperando: um loop local de execução e depuração para agentes IA.

PC Chan publicou o resumo completo, e embora haja muito conteúdo, deixe-me filtrar o que realmente importa para desenvolvedores .NET construindo apps com IA.

Executar e depurar agentes IA sem fazer deploy

Esta é a grande novidade. A nova extensão azure.ai.agents adiciona comandos que te dão uma experiência de loop interno adequada para agentes IA:

azd ai agent run — inicia seu agente localmente
azd ai agent invoke — envia mensagens (local ou em produção)
azd ai agent show — mostra status e saúde do container
azd ai agent monitor — transmite logs do container em tempo real

Antes, testar um agente IA significava fazer deploy no Microsoft Foundry toda vez que você fazia uma mudança. Agora você pode iterar localmente, testar o comportamento do seu agente, e só fazer deploy quando estiver pronto.

GitHub Copilot configura seu projeto azd

azd init agora oferece uma opção “Set up with GitHub Copilot (Preview)”. Em vez de responder prompts manualmente, um agente Copilot gera a configuração para você. Quando um comando falha, azd oferece troubleshooting assistido por IA — tudo sem sair do terminal.

Container App Jobs e melhorias de deploy

Container App Jobs: azd agora faz deploy de Microsoft.App/jobs pela config existente host: containerapp.
Timeouts configuráveis: Nova flag --timeout no azd deploy e campo deployTimeout no azure.yaml.
Fallback de build remoto: Quando o build ACR falha, azd faz fallback automático para Docker/Podman local.
Validação preflight local: Parâmetros Bicep são validados localmente antes do deploy.

Melhorias de DX

Detecção automática de pnpm/yarn para projetos JS/TS
Suporte a pyproject.toml para Python
Diretórios de templates locais — azd init --template aceita caminhos do sistema de arquivos
Melhores mensagens de erro no modo --no-prompt
Variáveis de ambiente de build injetadas em todos os subprocessos de build (.NET, Node.js, Java, Python)

Conclusão

O loop de depuração local de agentes IA é a estrela desta versão, mas o acúmulo de melhorias de deploy e refinamento de DX faz o azd parecer mais maduro do que nunca. Se você está fazendo deploy de apps .NET no Azure — especialmente agentes IA — esta atualização vale a pena.

Confira as notas completas da versão para todos os detalhes.

O Dashboard do Aspire 13.2 agora tem uma API de telemetria — e isso muda tudo

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Se você tem desenvolvido aplicações distribuídas com .NET Aspire, já sabe que o dashboard é a melhor coisa de toda a experiência. Todos os seus traces, logs e métricas em um só lugar — sem Jaeger externo, sem configuração de Seq, sem momentos de “deixa eu verificar o outro terminal”.

O Aspire 13.2 acabou de melhorar tudo significativamente. James Newton-King anunciou a atualização, e honestamente? Os recursos de exportação de telemetria e a API sozinhos justificam o upgrade.

Exportar telemetria de forma civilizada

Aqui está o cenário que todos já vivemos: você está depurando um problema distribuído, finalmente reproduz depois de vinte minutos de configuração, e agora precisa compartilhar o que aconteceu com o time. Antes? Screenshots. Copiar e colar IDs de traces. A bagunça de sempre.

O Aspire 13.2 adiciona um diálogo de Gerenciar logs e telemetria onde você pode:

Limpar toda a telemetria (útil antes de tentar reproduzir)
Exportar telemetria selecionada em um arquivo ZIP no formato padrão OTLP/JSON
Reimportar esse ZIP em qualquer dashboard Aspire depois

Esse último ponto é o recurso matador. Você reproduz um bug, exporta a telemetria, anexa ao seu work item, e seu colega pode importar no próprio dashboard para ver exatamente o que você viu. Acabou o “consegue reproduzir na sua máquina?”

Traces, spans e logs individuais também têm uma opção “Export JSON” nos menus de contexto. Precisa compartilhar um trace específico? Clique direito, copiar JSON, colar na descrição do PR. Pronto.

A API de telemetria é o verdadeiro divisor de águas

Isso é o que mais me empolga. O dashboard agora expõe uma API HTTP em /api/telemetry para consultar dados de telemetria programaticamente. Endpoints disponíveis:

GET /api/telemetry/resources — listar recursos com telemetria
GET /api/telemetry/spans — consultar spans com filtros
GET /api/telemetry/logs — consultar logs com filtros
GET /api/telemetry/traces — listar traces
GET /api/telemetry/traces/{traceId} — obter todos os spans de um trace específico

Tudo retorna no formato OTLP JSON. Isso alimenta os novos comandos CLI aspire agent mcp e aspire otel, mas a implicação real é maior: agora você pode construir ferramentas, scripts e integrações com agentes de IA que consultam a telemetria da sua app diretamente.

Imagine um agente de IA que pode ver seus traces distribuídos reais enquanto você depura. Isso não é mais hipotético — é o que esta API possibilita.

Telemetria GenAI fica prática

Se você está construindo apps com IA usando Semantic Kernel ou Microsoft.Extensions.AI, vai gostar do visualizador de telemetria GenAI melhorado. O Aspire 13.2 adiciona:

Descrições de ferramentas IA renderizadas como Markdown
Um botão dedicado de GenAI na página de traces para acesso rápido
Melhor tratamento de erros para JSON de GenAI truncado ou não padrão
Navegação click-to-highlight entre definições de ferramentas

O post menciona que VS Code Copilot chat, Copilot CLI e OpenCode suportam configurar um OTEL_EXPORTER_OTLP_ENDPOINT. Aponte-os para o dashboard Aspire e você pode literalmente assistir seus agentes IA pensando em tempo real pela telemetria. Essa é uma experiência de depuração que você não encontra em nenhum outro lugar.

Conclusão

O Aspire 13.2 transforma o dashboard de “UI bonita de depuração” para “plataforma de observabilidade programável”. O workflow de exportação/importação sozinho economiza tempo real na depuração distribuída, e a API de telemetria abre a porta para diagnósticos assistidos por IA.

Se você já usa Aspire, atualize. Se não — esta é uma boa razão para conhecer aspire.dev.

KubeCon Europe 2026: O que os desenvolvedores .NET realmente precisam saber

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Sabe aquela sensação quando cai um post gigante de anúncios e você fica scrollando pensando “legal, mas o que isso muda pra mim na prática”? É assim que me sinto toda temporada de KubeCon.

A Microsoft acabou de publicar o resumo completo da KubeCon Europe 2026 — escrito pelo próprio Brendan Burns — e sinceramente? Tem conteúdo real aqui. Não são apenas checklists de features, mas melhorias operacionais que mudam como você gerencia as coisas em produção.

Deixa eu explicar o que realmente importa para nós desenvolvedores .NET.

mTLS sem o imposto do service mesh

A coisa com service meshes é: todo mundo quer as garantias de segurança, ninguém quer a carga operacional. O AKS finalmente está fechando essa lacuna.

Azure Kubernetes Application Network te dá TLS mútuo, autorização com reconhecimento de aplicação e telemetria de tráfego — sem implantar um mesh pesado com sidecars. Combinado com Cilium mTLS no Advanced Container Networking Services, você tem comunicação criptografada pod-a-pod usando certificados X.509 e SPIRE para gerenciamento de identidade.

Na prática: suas APIs ASP.NET Core conversando com workers em background, seus serviços gRPC chamando uns aos outros — tudo criptografado e verificado por identidade no nível de rede, sem nenhuma alteração no código. Isso é enorme.

Para times migrando do ingress-nginx, também tem Application Routing com Meshless Istio com suporte completo à Kubernetes Gateway API. Sem sidecars. Baseado em padrões. E lançaram ferramentas ingress2gateway para migração incremental.

Observabilidade de GPU que não é secundária

Se você está rodando inferência de IA junto com seus serviços .NET (e sejamos honestos, quem não está começando?), provavelmente já se deparou com o ponto cego do monitoramento de GPU. Tinha dashboards ótimos de CPU/memória e depois… nada para GPUs sem configuração manual de exportadores.

AKS agora expõe métricas de GPU nativamente no Prometheus e Grafana gerenciados. Mesmo stack, mesmos dashboards, mesmo pipeline de alertas. Sem exportadores custom, sem agentes de terceiros.

No lado de rede, adicionaram visibilidade por fluxo para tráfego HTTP, gRPC e Kafka com uma experiência one-click no Azure Monitor. IPs, portas, workloads, direção do fluxo, decisões de policy — tudo em dashboards integrados.

E aqui vem a que me fez olhar duas vezes: agentic container networking adiciona uma UI web onde você pode fazer perguntas em linguagem natural sobre o estado de rede do seu cluster. “Por que o pod X não alcança o serviço Y?” → diagnósticos read-only a partir de telemetria ao vivo. Genuinamente útil às 2 da manhã.

Networking cross-cluster que não exige doutorado

Multi-cluster em Kubernetes historicamente foi uma experiência de “traga sua própria cola de rede”. Azure Kubernetes Fleet Manager agora entrega networking cross-cluster através de Cilium cluster mesh gerenciado:

Conectividade unificada entre clusters AKS
Registro global de serviços para descoberta cross-cluster
Configuração gerenciada centralmente, não repetida por cluster

Se você roda microsserviços .NET em várias regiões para resiliência ou compliance, isso substitui muita cola custom frágil. O Serviço A no West Europe pode descobrir e chamar o Serviço B no East US através do mesh, com políticas de roteamento e segurança consistentes.

Upgrades que não exigem coragem

Sejamos honestos — upgrades de Kubernetes em produção são estressantes. “Atualizar e torcer” tem sido a estratégia de facto para muitos times, e é a razão principal pela qual clusters ficam defasados nas versões.

Duas novas capacidades mudam isso:

Blue-green agent pool upgrades criam um pool de nós paralelo com a nova configuração. Valide o comportamento, mova tráfego gradualmente e mantenha um caminho limpo de rollback. Nada mais de mutações in-place em nós de produção.

Agent pool rollback permite reverter um pool de nós para a versão anterior do Kubernetes e imagem de nó quando um upgrade dá errado — sem reconstruir o cluster.

Juntos, finalmente dão aos operadores controle real sobre o ciclo de vida de upgrades. Para times .NET, isso importa porque a velocidade da plataforma controla diretamente quão rápido você pode adotar novos runtimes, patches de segurança e capacidades de rede.

Workloads de IA se tornam cidadãos de primeira classe no Kubernetes

O trabalho upstream em open-source é igualmente importante. Dynamic Resource Allocation (DRA) acabou de chegar em GA no Kubernetes 1.36, tornando o scheduling de GPU uma feature de primeira classe ao invés de um workaround.

Alguns projetos que vale a pena acompanhar:

Projeto	O que faz
AI Runway	API Kubernetes comum para inferência — deploy de modelos sem saber K8s, com descoberta HuggingFace e estimativas de custo
HolmesGPT	Troubleshooting agêntico para cloud-native — agora projeto CNCF Sandbox
Dalec	Builds declarativos de imagens de container com geração de SBOM — menos CVEs na fase de build

A direção é clara: sua API .NET, sua camada de orquestração com Semantic Kernel e seus workloads de inferência deveriam todos rodar em um modelo de plataforma consistente. Estamos chegando lá.

Por onde eu começaria esta semana

Se você está avaliando essas mudanças para seu time, aqui vai minha lista honesta de prioridades:

Observabilidade primeiro — habilite métricas de GPU e logs de fluxo de rede em um cluster não-prod. Veja o que você andou perdendo.
Teste blue-green upgrades — experimente o workflow de rollback antes do seu próximo upgrade de cluster em produção. Construa confiança no processo.
Pilote networking com identidade — escolha um caminho de serviço interno e habilite mTLS com Cilium. Meça o overhead (spoiler: é mínimo).
Avalie Fleet Manager — se você roda mais de dois clusters, networking cross-cluster se paga sozinho em redução de cola custom.

Experimentos pequenos, feedback rápido. Essa é sempre a jogada.

Finalizando

Anúncios de KubeCon podem ser avassaladores, mas essa leva realmente move a agulha para times .NET no AKS. Melhor segurança de rede sem overhead de mesh, observabilidade real de GPU, upgrades mais seguros e fundações mais fortes para infraestrutura de IA.

Se você já está no AKS, é um ótimo momento para reforçar sua baseline operacional. E se está planejando mover workloads .NET para Kubernetes — a plataforma ficou significativamente mais pronta para produção.

Foundry Agent Service está GA: O que realmente importa para construtores de agentes .NET

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Vamos ser honestos — construir um protótipo de agente IA é a parte fácil. A parte difícil é tudo o que vem depois: colocá-lo em produção com isolamento de rede adequado, executar avaliações que realmente signifiquem algo, lidar com requisitos de conformidade e não quebrar nada às 2 da manhã.

O Foundry Agent Service acabou de chegar ao GA, e esta versão está focada como um laser nessa lacuna do “tudo que vem depois”.

Construído sobre a Responses API

A manchete: o Foundry Agent Service de próxima geração é construído sobre a OpenAI Responses API. Se você já está construindo com esse protocolo, migrar para o Foundry requer mudanças mínimas de código. O que você ganha: segurança empresarial, rede privada, RBAC Entra, rastreamento completo e avaliação — sobre sua lógica de agente existente.

A arquitetura é intencionalmente aberta. Você não está preso a um provedor de modelo ou um framework de orquestração. Use DeepSeek para planejamento, OpenAI para geração, LangGraph para orquestração — o runtime cuida da camada de consistência.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Rede privada: o bloqueador empresarial removido

Esta é a funcionalidade que desbloqueia a adoção empresarial. Foundry agora suporta rede privada completa de ponta a ponta com BYO VNet:

Sem egress público — o tráfego do agente nunca toca a internet pública
Injeção de contêiners/sub-redes na sua rede para comunicação local
Conectividade de ferramentas incluída — servidores MCP, Azure AI Search, agentes de dados Fabric, todos operam sobre caminhos privados

Esse último ponto é crítico. Não são apenas as chamadas de inferência que ficam privadas — cada invocação de ferramenta e chamada de recuperação também fica dentro do perímetro da sua rede. Para equipes operando sob políticas de classificação de dados que proíbem roteamento externo, isso era o que faltava.

Autenticação MCP feita direito

Conexões de servidores MCP agora suportam o espectro completo de padrões de autenticação:

Método de auth	Quando usar
Baseado em chave	Acesso compartilhado simples para ferramentas internas da organização
Entra Agent Identity	Serviço a serviço; o agente se autentica como ele mesmo
Entra Managed Identity	Isolamento por projeto; sem gerenciamento de credenciais
OAuth Identity Passthrough	Acesso delegado por usuário; agente age em nome dos usuários

OAuth Identity Passthrough é o interessante. Quando usuários precisam dar a um agente acesso aos seus dados pessoais — seu OneDrive, sua organização Salesforce, uma API SaaS com escopo por usuário — o agente age em seu nome com fluxos OAuth padrão. Sem identidade de sistema compartilhada fingindo ser todos.

Voice Live: voz a voz sem a encanação

Adicionar voz a um agente costumava significar juntar STT, LLM e TTS — três serviços, três saltos de latência, três superfícies de faturamento, tudo sincronizado à mão. Voice Live colapsa isso em uma única API gerenciada com:

Detecção semântica de atividade de voz e fim de turno (entende significado, não apenas silêncio)
Supressão de ruído e cancelamento de eco do lado do servidor
Suporte a barge-in (usuários podem interromper no meio da resposta)

Interações de voz passam pelo mesmo runtime de agente que o texto. Mesmos avaliadores, mesmos traces, mesma visibilidade de custos. Para suporte ao cliente, serviço de campo ou cenários de acessibilidade, isso substitui o que antes requeria um pipeline de áudio personalizado.

Avaliações: de checkbox para monitoramento contínuo

Aqui é onde o Foundry fica sério sobre qualidade em produção. O sistema de avaliação agora tem três camadas:

Avaliadores prontos para uso — coerência, relevância, fundamentação, qualidade de recuperação, segurança. Conecte a um dataset ou tráfego ao vivo e obtenha pontuações.
Avaliadores personalizados — codifique sua própria lógica de negócio, padrões de tom e regras de conformidade específicas do domínio.
Avaliação contínua — Foundry amostra tráfego de produção ao vivo, executa sua suíte de avaliadores e exibe resultados em dashboards. Configure alertas do Azure Monitor para quando a fundamentação cai ou limites de segurança são violados.

Tudo é publicado no Azure Monitor Application Insights. Qualidade do agente, saúde da infraestrutura, custo e telemetria da aplicação — tudo em um só lugar.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Seis novas regiões para agentes hospedados

Agentes hospedados agora estão disponíveis em East US, North Central US, Sweden Central, Southeast Asia, Japan East e mais. Isso importa para requisitos de residência de dados e para comprimir latência quando seu agente roda perto de suas fontes de dados.

Por que isso importa para desenvolvedores .NET

Embora os exemplos de código no anúncio de GA sejam Python-first, a infraestrutura subjacente é agnóstica a linguagem — e o SDK .NET para azure-ai-projects segue os mesmos padrões. A Responses API, o framework de avaliação, a rede privada, a autenticação MCP — tudo isso está disponível a partir do .NET.

Se você tem esperado os agentes IA passarem de “demo legal” para “consigo realmente entregar isso no trabalho”, esta versão GA é o sinal. Rede privada, autenticação adequada, avaliação contínua e monitoramento de produção são as peças que faltavam.

Para finalizar

Foundry Agent Service está disponível agora. Instale o SDK, abra o portal e comece a construir. O guia de início rápido leva você de zero a um agente rodando em minutos.

Para o mergulho técnico completo com todos os exemplos de código, confira o anúncio de GA.

Respostas em segundo plano no Microsoft Agent Framework: chega de ansiedade com timeouts

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Se você já construiu algo com modelos de raciocínio como o3 ou GPT-5.2, conhece a dor. Seu agente começa a pensar numa tarefa complexa, o cliente fica esperando, e em algum ponto entre “tá tudo bem” e “será que travou?” sua conexão expira por timeout. Todo aquele trabalho? Perdido.

O Microsoft Agent Framework acabou de lançar respostas em segundo plano — e honestamente, essa é uma daquelas funcionalidades que deveria ter existido desde o primeiro dia.

O problema com chamadas bloqueantes

Num padrão tradicional de requisição-resposta, seu cliente bloqueia até o agente terminar. Funciona bem para tarefas rápidas. Mas quando você pede a um modelo de raciocínio que faça pesquisa profunda, análise em múltiplas etapas, ou gere um relatório de 20 páginas? São minutos de tempo real. Durante essa janela:

Conexões HTTP podem expirar
Quedas de rede matam toda a operação
Seu usuário fica olhando um spinner se perguntando se algo está acontecendo

Respostas em segundo plano invertem isso completamente.

Como os tokens de continuação funcionam

Em vez de bloquear, você dispara a tarefa do agente e recebe um token de continuação. Pense nisso como um ticket de retirada numa oficina — você não fica parado no balcão esperando, volta quando está pronto.

O fluxo é direto:

Envie sua requisição com AllowBackgroundResponses = true
Se o agente suporta processamento em segundo plano, você recebe um token de continuação
Consulte no seu ritmo até o token retornar null — isso significa que o resultado está pronto

Aqui está a versão .NET:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Consultar até completar
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Se o agente completa imediatamente (tarefas simples, modelos que não precisam de processamento em segundo plano), nenhum token de continuação é retornado. Seu código simplesmente funciona — sem tratamento especial necessário.

Streaming com retomada: a verdadeira mágica

Polling é bom para cenários de disparar e esquecer, mas e quando você quer progresso em tempo real? Respostas em segundo plano também suportam streaming com retomada embutida.

Cada atualização do stream carrega seu próprio token de continuação. Se sua conexão cair no meio do stream, você retoma exatamente de onde parou:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simular uma interrupção de rede
}

// Retomar exatamente de onde paramos
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

O agente continua processando no servidor independentemente do que aconteça com seu cliente. Isso é tolerância a falhas embutida sem que você escreva lógica de retry ou circuit breakers.

Quando realmente usar isso

Nem toda chamada ao agente precisa de respostas em segundo plano. Para completações rápidas, você está adicionando complexidade sem razão. Mas aqui é onde elas brilham:

Tarefas de raciocínio complexo — análise em múltiplas etapas, pesquisa profunda, qualquer coisa que faça um modelo de raciocínio realmente pensar
Geração de conteúdo longo — relatórios detalhados, documentos de múltiplas partes, análises extensas
Redes pouco confiáveis — clientes móveis, deployments no edge, VPNs corporativas instáveis
Padrões UX assíncronos — envie uma tarefa, vá fazer outra coisa, volte para os resultados

Para nós desenvolvedores .NET construindo apps empresariais, esse último é particularmente interessante. Pense numa app Blazor onde um usuário solicita um relatório complexo — você dispara a tarefa do agente, mostra um indicador de progresso, e os deixa continuar trabalhando. Sem ginástica de WebSocket, sem infraestrutura de filas personalizada, apenas um token e um loop de polling.

Para finalizar

Respostas em segundo plano estão disponíveis agora tanto em .NET quanto em Python através do Microsoft Agent Framework. Se você está construindo agentes que fazem algo mais complexo que simples Q&A, vale a pena adicionar isso ao seu toolkit. O padrão de token de continuação mantém as coisas simples enquanto resolve um problema de produção muito real.

Confira a documentação completa para a referência completa da API e mais exemplos.

VS Code 1.112: O que desenvolvedores .NET realmente deveriam se importar

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

VS Code 1.112 acabou de chegar, e honestamente? Este aqui bate diferente se você passa seus dias em território .NET. Tem muita coisa nas notas de versão oficiais, mas deixe-me poupar alguma rolagem e focar no que realmente importa para nós.

Copilot CLI ficou muito mais útil

O grande tema desta versão é a autonomia do agente — dar ao Copilot mais espaço para fazer seu trabalho sem você supervisionar cada passo.

Direcionamento e fila de mensagens

Sabe aquele momento quando o Copilot CLI está no meio de uma tarefa e você percebe que esqueceu de mencionar algo? Antes, você tinha que esperar. Agora pode enviar mensagens enquanto uma requisição ainda está em andamento — seja para direcionar a resposta atual ou enfileirar instruções de acompanhamento.

Isso é enorme para aquelas tarefas mais longas de scaffolding dotnet onde você está assistindo o Copilot configurar um projeto e pensa “oh espera, também preciso de MassTransit ali”.

Níveis de permissão

Este é o que mais me empolga. Sessões do Copilot CLI agora suportam três níveis de permissão:

Permissões padrão — o fluxo usual onde as ferramentas pedem confirmação antes de executar
Ignorar aprovações — auto-aprova tudo e tenta novamente em erros
Autopiloto — totalmente autônomo: aprova ferramentas, responde suas próprias perguntas e continua até a tarefa estar completa

Se você está fazendo algo como criar uma nova API ASP.NET Core com Entity Framework, migrations e setup Docker — o modo Autopiloto significa que você descreve o que quer e vai pegar um café. Ele vai resolver.

Você pode habilitar o Autopiloto com a configuração chat.autopilot.enabled.

Pré-visualizar mudanças antes de delegar

Quando você delega uma tarefa ao Copilot CLI, ele cria um worktree. Antes, se você tivesse mudanças não commitadas, tinha que verificar o Controle de Código Fonte para ver o que seria afetado. Agora a visualização do Chat mostra as mudanças pendentes ali mesmo antes de você decidir se copia, move ou ignora.

Coisa pequena, mas salva você daquele momento de “espera, o que eu tinha no staging?”.

Depure apps web sem sair do VS Code

O navegador integrado agora suporta depuração completa. Você pode colocar breakpoints, fazer step through do código e inspecionar variáveis — tudo dentro do VS Code. Acabou o trocar para Edge DevTools.

Há um novo tipo de debug editor-browser, e se você já tem configurações de lançamento msedge ou chrome existentes, migrar é tão simples quanto mudar o campo type no seu launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Para desenvolvedores Blazor, isso é um divisor de águas. Você já está executando dotnet watch no terminal — agora sua depuração fica na mesma janela também.

O navegador também ganhou níveis de zoom independentes (finalmente), menus de contexto com clique direito apropriados, e o zoom é lembrado por site.

Sandboxing de servidores MCP

Isso importa mais do que você imagina. Se você está usando servidores MCP — talvez tenha configurado um personalizado para seus recursos Azure ou consultas de banco de dados — eles estavam rodando com as mesmas permissões do seu processo VS Code. Isso significa acesso total ao seu sistema de arquivos, rede, tudo.

Agora você pode colocá-los em sandbox. No seu mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Quando um servidor em sandbox precisa de acesso a algo que não tem, o VS Code solicita que você conceda permissão. Muito melhor que a abordagem de “torcer para ninguém fazer nada estranho”.

Descoberta de personalizações em monorepos

Se você trabalha em um monorepo (e sejamos honestos, muitas soluções .NET empresariais acabam virando um), isso resolve um ponto de dor real.

Anteriormente, se você abria uma subpasta do seu repositório, o VS Code não encontrava seu copilot-instructions.md, AGENTS.md, ou skills personalizados na raiz do repositório. Agora com a configuração chat.useCustomizationsInParentRepositories, ele sobe até a raiz .git e descobre tudo.

Isso significa que seu time pode compartilhar instruções de agente, arquivos de prompt e ferramentas personalizadas entre todos os projetos em um monorepo sem que todos precisem abrir a pasta raiz.

/troubleshoot para depuração de agentes

Já configurou instruções personalizadas ou skills e se perguntou por que não estão sendo detectados? O novo skill /troubleshoot lê os logs de depuração do agente e te diz o que aconteceu — quais ferramentas foram usadas ou puladas, por que as instruções não carregaram, e o que está causando respostas lentas.

Habilite com:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Então simplesmente digite /troubleshoot why is my custom skill not loading? no chat.

Você também pode exportar e importar esses logs de depuração agora, o que é ótimo para compartilhar com seu time quando algo não está funcionando como esperado.

Suporte a arquivos de imagem e binários

Agentes agora podem ler arquivos de imagem do disco e arquivos binários nativamente. Os arquivos binários são apresentados em formato hexdump, e saídas de imagem (como capturas de tela do navegador integrado) aparecem em uma visualização de carrossel.

Para desenvolvedores .NET, pense: cole uma captura de tela de um bug de UI no chat e faça o agente entender o que está errado, ou faça-o analisar a saída de renderização de um componente Blazor.

Referências automáticas de símbolos

Pequena melhoria de qualidade de vida: quando você copia o nome de um símbolo (uma classe, método, etc.) e cola no chat, o VS Code agora automaticamente converte em uma referência #sym:Name. Isso dá ao agente contexto completo sobre aquele símbolo sem você ter que adicioná-lo manualmente.

Se quiser texto puro, use Ctrl+Shift+V.

Plugins agora podem ser habilitados/desabilitados

Anteriormente, desabilitar um servidor MCP ou plugin significava desinstalá-lo. Agora você pode ligá-los e desligá-los — tanto globalmente quanto por workspace. Clique direito na visualização de Extensões ou na visualização de Personalizações e pronto.

Plugins de npm e pypi também podem se auto-atualizar agora, embora peçam aprovação primeiro já que atualizações significam executar código novo na sua máquina.

Para finalizar

VS Code 1.112 está claramente empurrando forte na experiência do agente — mais autonomia, melhor depuração, segurança mais apertada. Para desenvolvedores .NET, a depuração do navegador integrado e as melhorias do Copilot CLI são as funcionalidades destaque.

Se você ainda não experimentou rodar uma sessão completa do Copilot CLI em modo Autopiloto para um projeto .NET, esta versão é um bom momento para começar. Só lembre de configurar suas permissões e deixar cozinhar.

Baixar VS Code 1.112 ou atualizar de dentro do VS Code via Ajuda > Verificar Atualizações.

Dotnet | The .NET Blog

SDD Conference 2026

Tópicos

Palestrantes

Ingressos e informações

Hooks do azd em Python, TypeScript e .NET: chega de scripts shell

Hooks, brevemente

Como funciona a detecção

Detalhes por linguagem

Python

JavaScript e TypeScript

.NET

Configuração por executor

Por que isso importa para desenvolvedores .NET

Conclusão

Windows App Dev CLI v0.3: F5 a partir do terminal e automação de UI para agentes

winapp run: F5 a partir de qualquer lugar

Novo pacote NuGet: dotnet run para apps empacotadas

winapp ui: UI Automation a partir da linha de comando

Outras novidades

Como obter

Pare de ficar de olho no seu terminal: o modo desacoplado do Aspire muda o fluxo de trabalho

Modo desacoplado: um comando, terminal de volta

Gerenciando o que está rodando

Combine com o modo isolado

Por que isso é enorme para agentes de código

Finalizando

Clustering de Pins Finalmente Chega ao .NET MAUI Maps — Uma Propriedade, Zero Dor de Cabeça

Uma propriedade para governar todos

Grupos de clustering independentes

Tratamento de taps em clusters

Detalhes de plataforma que vale a pena conhecer

Por que isso importa

Comece agora

.NET Abril 2026 Servicing — Patches de segurança que você deve aplicar hoje

O que foi corrigido

Versões atualizadas

O que fazer

Azure MCP Server 2.0 Chegou — Automação Agnóstica em Nuvem Self-Hosted Está Aqui

O que é Azure MCP Server?

O grande destaque: implantações remotas self-hosted

Endurecimento de segurança

Onde você pode usá-lo?

Por que isso importa para desenvolvedores .NET

Começando

Resumindo

.NET Aspire 13.2 Quer Ser o Melhor Amigo do Seu Agente de IA

O problema é real

Aspire como infraestrutura para agentes

A analogia dos para-choques de boliche

Primeiros passos

Concluindo

A avaliação de modernização do GitHub Copilot é a melhor ferramenta de migração que você ainda não está usando

Não é apenas um motor de sugestões de código

Duas formas de começar

O detalhamento de issues é acionável

Os caminhos de upgrade cobertos

Minha opinião

Finalizando

Conecte seus servidores MCP no Azure Functions aos Foundry Agents — Veja como

Por que essa combinação faz sentido

Opções de autenticação

Configurando

Minha opinião

Finalizando

MCP Apps ganham uma API fluente — Construa interfaces ricas para ferramentas de IA em .NET em três passos

O que são MCP Apps?

A API fluente em três passos

A superfície da API é bem projetada

Primeiros passos

Finalizando

O Modo Isolado do Aspire Resolve o Pesadelo de Conflitos de Porta no Desenvolvimento Paralelo

A solução: --isolated

Cenários reais onde isso brilha

Como funciona internamente

Quando usar

Concluindo

C# 15 ganha Union Types — e são exatamente o que estávamos pedindo

O problema que as uniões resolvem

A sintaxe é lindamente simples

A solução: `--isolated`