The .NET Blog

NDC Oslo 2026

Mon, 14 Sep 2026 00:00:00 +0000

NDC Oslo 2026 acontece de 14 a 18 de setembro de 2026 no Oslo Spektrum, Oslo, Noruega.

NDC Oslo é uma das maiores e mais respeitadas conferências de desenvolvedores da Europa, cobrindo tudo, desde .NET e cloud até segurança, arquitetura, IA e muito mais. A edição 2026 está atualmente em fase de reservas, com uma programação massiva em preparação.

Em números

160 sessões (em reserva)
150 palestrantes (em reserva)
15 workshops (em reserva)
5 dias — workshops + conferência

Palestrantes confirmados

A lista de palestrantes está sendo construída, com nomes confirmados incluindo:

Nick Chapsas
Maddy Montaquila
Troy Hunt
Kevlin Henney
Venkat Subramaniam
Jeff Fritz
Philippe De Ryck
Nhlanhla Lucky Nkosi
Aleksander Stensby

Ingressos

Ingressos Early Bird estão disponíveis — a oferta Early Bird termina em 22 de maio de 2026.

O CFP (Call for Papers) também está aberto.

Outros eventos NDC em 2026

NDC Sydney — 22–24 de abril, 2026
NDC Toronto — 5–8 de maio, 2026
NDC Copenhagen — 1–4 de junho, 2026
NDC AI — 8–10 de junho, 2026
NDC TechTown — 21–24 de setembro, 2026

.NET Day Switzerland 2026

Tue, 25 Aug 2026 00:00:00 +0000

.NET Day Switzerland 2026 acontece em 25 de agosto de 2026 no Arena Cinemas Sihlcity (Kalanderplatz 8, 8045 Zurique).

É uma conferência comunitária independente e sem fins lucrativos para desenvolvedores, arquitetos e especialistas discutirem .NET, C#, ASP.NET Core, Azure e o ecossistema de desenvolvimento Microsoft. Todos os palestrantes e equipe são voluntários, e qualquer excedente da venda de ingressos é destinado a caridade ou à comunidade .NET suíça.

O que você recebe

Sessões de alta qualidade com especialistas internacionais
Networking com outros participantes
Comida, snacks e bebidas durante os intervalos, almoço e aperitivo
Oportunidades de carreira através de interações com patrocinadores
Conversas diretas com palestrantes durante os intervalos

Ingressos

Categoria	Preço	Disponibilidade
Very Early Bird (1–30 Abr)	299 CHF	Máx. 100 ingressos
Early Bird	399 CHF	Máx. 100 ingressos
Regular	449 CHF	Até esgotar

Palestrantes e programação ainda não foram anunciados — a chamada para palestrantes está aberta no Sessionize.

Organizadores

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.

Atualização de Abril do Azure DevOps MCP Server: Consultas WIQL, Auth PAT e MCP Apps Experimental

Emiliano Montesdeoca — Mon, 27 Apr 2026 00:00:00 +0000

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

O Azure DevOps MCP Server continua melhorando. A atualização de abril cobre ambos os servidores.

Suporte a Consultas WIQL

A nova ferramenta wit_query_by_wiql permite executar consultas Work Item Query Language diretamente do seu cliente MCP.

Personal Access Tokens

Autenticação PAT no servidor local — importante para cenários de integração sem autenticação interativa.

Anotações MCP

Tags de metadados para ferramentas somente leitura, destrutivas e open-world — fundamentais para a confiabilidade dos agentes.

Consolidação das Ferramentas Wiki

5 ferramentas wiki separadas → 2 ferramentas mais capazes. Menos ferramentas = melhor desempenho do LLM.

Experimental: MCP Apps

Fluxos de trabalho empacotados no ambiente do servidor MCP. A direção está certa.

Post original de Dan Hellem: Azure DevOps MCP Server April Update.

SQL Server 2025 como Banco de Dados Pronto para Agentes: Segurança, Backup e MCP em Um Motor

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

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

Acompanhei a série Polyglot Tax de Aditya Badramraju com muito interesse. A parte 4 fecha a série com as partes que realmente determinam se você confiaria nessa arquitetura em produção.

Um Modelo de Segurança para Todos os Modelos de Dados

Uma única política de Row-Level Security que cobre todos os modelos de dados. Uma política, uma prova para o auditor.

Backup Unificado = Recuperação Atômica

Em um stack poliglota, recuperação point-in-time em cinco bancos de dados é um pesadelo de consistência. Com um banco, é atômica por definição.

Integração MCP: Agentes Sem Middleware

SQL Server 2025 suporta o SQL MCP Server diretamente. Agentes chamam ferramentas, o motor impõe isolamento de tenant e mascaramento de colunas automaticamente.

Post original de Aditya Badramraju: The Polyglot Tax – Part 4.

.NET 10 Vem com Ubuntu 26.04 LTS — O que há de Novo

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

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

É o dia do Ubuntu LTS. Ubuntu 26.04 (Resolute Raccoon) chegou hoje com .NET 10.

LTS sobre LTS — cinco anos de suporte para o OS, alinhados com a janela de suporte de longo prazo do .NET 10.

Instale .NET 10 em dois comandos

sudo apt update
sudo apt install dotnet-sdk-10.0

Contêineres: atualize `-noble` para `-resolute`

sed -i "s/noble/resolute/g" Dockerfile

Native AOT: inicialização em 3ms, binário de 1,4MB

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# binário nativo de 1,4MB, inicialização em 3ms

Para cargas de trabalho cloud-native onde o tempo de cold-start importa — Functions, contêineres, serverless — uma mudança real.

Precisa de .NET 8 ou 9?

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

O post completo tem mais detalhes sobre cgroup v2, criptografia pós-quântica e Linux 7.0.

Azure SDK Abril 2026: AI Foundry 2.0 e o Que Desenvolvedores .NET Devem Saber

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

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

Lançamentos mensais do SDK são fáceis de ignorar. Este tem algumas coisas que merecem atenção — especialmente se você constrói com AI Foundry, Cosmos DB em Java, ou faz provisionamento de infraestrutura a partir de código .NET.

Azure.AI.Projects 2.0.0 — Breaking Changes que Fazem Sentido

Splits de namespace, tipos renomeados, e convenção Is* consistente para booleanos.

Cosmos DB Java: Correção Crítica de Segurança (RCE)

Versão 4.79.0 corrige vulnerabilidade de Execução Remota de Código (CWE-502). Atualize imediatamente.

Novas Bibliotecas de Provisioning para .NET

Post original: Azure SDK Release (April 2026).

CodeAct no Agent Framework: Como Reduzir a Latência do seu Agente pela Metade

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

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

Existe aquele momento em todo projeto de agentes em que você olha para o trace e pensa: “por que isso está demorando tanto?” O modelo está ótimo. As ferramentas funcionam. Mas há sete round trips para obter um resultado que poderia ser calculado de uma só vez.

Esse é exatamente o problema que o CodeAct resolve — e a equipe do Agent Framework acabou de lançar suporte alpha via o novo pacote agent-framework-hyperlight.

O que é CodeAct?

O padrão CodeAct é elegantemente simples: em vez de dar ao modelo uma lista de ferramentas para chamar uma por uma, você dá a ele uma única ferramenta execute_code e deixa-o expressar o plano completo como um curto programa Python. O agente escreve o código uma vez, o sandbox o executa, e você recebe de volta um único resultado consolidado.

Fiação	Tempo	Tokens
Tradicional	27,81s	6.890
CodeAct	13,23s	2.489
Melhoria	52,4%	63,9%

A peça de segurança: Micro-VMs do Hyperlight

O pacote agent-framework-hyperlight usa micro-VMs do Hyperlight. Cada chamada execute_code obtém sua própria micro-VM recém-criada. A inicialização é medida em milissegundos. O isolamento é essencialmente gratuito.

Suas ferramentas continuam sendo executadas no host. O código de cola gerado pelo modelo é executado no sandbox. Essa é a divisão correta.

Configuração mínima

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Quando usar o CodeAct (e quando não usar)

Use o CodeAct quando:

A tarefa encadeia muitas chamadas pequenas de ferramentas (lookups, joins, cálculos)
A latência e o custo de tokens importam
Você quer isolamento forte por chamada no código gerado pelo modelo

Fique com o tool-calling tradicional quando:

O agente só faz uma ou duas chamadas de ferramentas por turno
Cada chamada tem efeitos colaterais a serem aprovados individualmente
As descrições de ferramentas são esparsas ou ambíguas

Experimente agora

pip install agent-framework-hyperlight --pre

Confira o post completo no blog do Agent Framework para uma cobertura mais profunda.

GPT-5.5 Chegou ao Azure Foundry — O que Desenvolvedores .NET Precisam Saber

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

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

A Microsoft acaba de anunciar que GPT-5.5 está geralmente disponível no Microsoft Foundry. Se você tem construído agentes no Azure, esta é a atualização que você estava esperando.

A progressão do GPT-5

GPT-5: unificou raciocínio e velocidade em um único sistema
GPT-5.4: raciocínio multi-etapas mais sólido, capacidades agênticas para empresas
GPT-5.5: raciocínio de contexto longo mais profundo, execução agêntica mais confiável, maior eficiência de tokens

O que realmente mudou

Codificação agêntica aprimorada: GPT-5.5 mantém contexto em grandes bases de código, diagnostica falhas arquiteturais e antecipa requisitos de testes. O modelo raciocina sobre o que mais uma correção afeta antes de agir.

Eficiência de tokens: Saídas de maior qualidade com menos tokens e menos tentativas. Custo e latência diretamente menores em produção.

Análise de contexto longo: Lida com documentos extensos e históricos multi-sessão sem perder o fio.

Preços

Modelo	Entrada ($/M tokens)	Entrada em cache	Saída ($/M tokens)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Por que o Foundry importa

O Foundry Agent Service permite definir agentes em YAML ou conectá-los com Microsoft Agent Framework, GitHub Copilot SDK, LangGraph ou OpenAI Agents SDK — e executá-los como agentes hospedados isolados com sistema de arquivos persistente, identidade Microsoft Entra e preços de escala a zero.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Você é um assistente útil.", name: "MeuAgente");

Veja o anúncio completo para todos os detalhes.

O Azure MCP Server Agora é um .mcpb — Instale-o sem Nenhum Runtime

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

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

Sabe o que era chato na configuração de servidores MCP? Você precisava de um runtime. Node.js para a versão npm, Python para pip/uvx, .NET SDK para a variante dotnet.

O Azure MCP Server acabou de mudar isso. Agora está disponível como .mcpb — um MCP Bundle — e a configuração é arrastar e soltar.

O que é um MCP Bundle?

Pense como uma extensão do VS Code (.vsix) ou extensão de navegador (.crx), mas para servidores MCP. Um arquivo .mcpb é um arquivo ZIP independente que inclui o binário do servidor e todas as suas dependências.

Como instalar

1. Baixe o bundle para sua plataforma

Vá para a página de GitHub Releases e baixe o arquivo .mcpb para seu OS e arquitetura.

2. Instale no Claude Desktop

O mais fácil: arraste e solte o arquivo .mcpb na janela do Claude Desktop na página de configurações de Extensões (☰ → Arquivo → Configurações → Extensões). Revise os detalhes, clique em Instalar, confirme.

3. Autentique no Azure

az login

Só isso. O Azure MCP Server usa suas credenciais Azure existentes.

O que você pode fazer

Mais de 100 ferramentas de serviços Azure diretamente do seu cliente IA:

Consultar e gerenciar Cosmos DB, Storage, Key Vault, App Service, Foundry
Gerar comandos az CLI para qualquer tarefa
Criar templates Bicep e Terraform

Para começar

Download: GitHub Releases
Repositório: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Veja o post completo.

Onde seu Agente se Lembra das Coisas? Guia Prático de Armazenamento do Histórico de Chat

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

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

Ao criar um agente IA, você gasta a maior parte da energia no modelo, nas ferramentas e nos prompts. A pergunta de onde vive o histórico de conversa parece um detalhe de implementação — mas é uma das decisões arquiteturais mais importantes que você tomará.

Ela determina se usuários podem bifurcar conversas, desfazer respostas, retomar sessões após uma reinicialização e se seus dados saem da sua infraestrutura. A equipe do Agent Framework publicou uma análise aprofundada.

Dois padrões fundamentais

Gerenciado pelo serviço: o serviço IA armazena o estado da conversa. Seu app mantém uma referência e o serviço inclui automaticamente o histórico relevante em cada requisição.

Gerenciado pelo cliente: seu app mantém o histórico completo e envia mensagens relevantes com cada requisição. O serviço é stateless. Você controla tudo.

Como o Agent Framework abstrai isso

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Meu nome é Alice.", session);
var second = await agent.RunAsync("Qual é o meu nome?", session);

session = agent.create_session()
first = await agent.run("Meu nome é Alice.", session=session)
second = await agent.run("Qual é o meu nome?", session=session)

Referência rápida de provedores

Provedor	Armazenamento	Modelo	Compactação
OpenAI/Azure Chat Completions	Cliente	N/A	Você
Foundry Agent Service	Serviço	Linear	Serviço
Responses API (padrão)	Serviço	Ramificável	Serviço
Anthropic Claude, Ollama	Cliente	N/A	Você

Como escolher

Precisa de ramificação ou “desfazer”? → Responses API gerenciado pelo serviço
Precisa de soberania de dados? → Gerenciado pelo cliente com provedor de banco de dados
É um chatbot simples? → Gerenciado pelo serviço linear está ótimo

Leia o post completo para a árvore de decisão completa.

VS Code 1.118: Copilot CLI Ganha Nomes de Sessão, Badges de Modelo e TypeScript 7.0 Nightly

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

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

Visual Studio Code 1.118 é um release menor e focado — principalmente refinamentos do Copilot CLI — mas há algumas coisas que merecem atenção.

Copilot CLI: sessões têm nomes reais

As APIs de título de sessão do SDK do Copilot CLI agora são a fonte da verdade para nomes de sessão. Sessões mostram o nome real do SDK em vez de etiquetas geradas automaticamente.

Troque de sessão mais rápido

O app Agents agora tem Ctrl+1, Ctrl+2, etc. para trocar rapidamente entre sessões.

Badges de modelo no chat

Respostas do Copilot CLI no painel de chat agora mostram um badge de modelo — você pode ver de relance qual modelo tratou cada requisição.

Seleção automática de modelo no Copilot CLI

A seleção automática de modelo agora funciona também no agente Copilot CLI.

Opt-in para TypeScript 7.0 Nightly

Você pode agora optar por testar os nightlies do TypeScript 7.0 diretamente nas configurações do VS Code. TypeScript 7.0 é um release importante (a beta foi lançada há alguns dias).

Veja as notas de release completas.

Aspire 13.2: Suporte a Bun, Melhores Contêineres e Menos Fricção no Debug

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

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

Se você vem construindo backends .NET com frontends JavaScript no Aspire, a 13.2 é o tipo de atualização que melhora seu dia silenciosamente.

Bun é Agora Cidadão de Primeira Classe

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

Se sua equipe já usa Bun, o Aspire não te força mais a nadar contra a corrente.

Yarn Ficou Mais Confiável

Usuários do Yarn recebem menos falhas misteriosas com withYarn() e addViteApp().

Melhorias em Contêineres

ImagePullPolicy.Never para usar a imagem local sem ir ao registry. PostgreSQL 18+ com volumes de dados agora funciona corretamente.

Melhorias de Debug

DebuggerDisplayAttribute em tipos core
Mensagens de erro melhores para WaitFor
BeforeResourceStartedEvent disparado no momento certo

Post original de David Pine: Aspire 13.2: Bun Support and Container Enhancements.

68 Minutos por Dia Re-Explicando Código? Existe uma Solução

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

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

Você conhece aquele momento quando sua sessão do Copilot chega no /compact e o agente esquece completamente o que você estava fazendo? Você passa os próximos cinco minutos re-explicando a estrutura de arquivos, o teste falhando, as três abordagens que já tentou. Então acontece de novo.

Desi Villanueva mediu: 68 minutos por dia — só em re-orientação. Não escrevendo código. Não revisando PRs. Só atualizando a IA sobre coisas que ela já sabia.

Acontece que há uma razão concreta para isso — e uma solução concreta.

A Mentira da Janela de Contexto

Seu agente vem com um número grande na caixa. 200K tokens. Parece massivo. Na prática é um teto, não uma garantia.

Aqui está a matemática real:

200K de contexto total
Menos ~65K para ferramentas MCP carregadas no início (~33%)
Menos ~10K para arquivos de instruções como AGENTS.md

Isso deixa você com aproximadamente 125K antes de digitar uma palavra. E piora — LLMs não degradam gradualmente. Eles batem em uma parede em torno de 60% de capacidade.

Limite efetivo: 45K tokens antes que a qualidade degrade.

O Imposto de Compactação

Cada /compact custa seu estado de flow. A parte cruel: a memória já existe. O Copilot CLI escreve cada sessão em um banco de dados SQLite local em ~/.copilot/session-store.db. O agente simplesmente não consegue lê-lo.

auto-memory: Uma Camada de Recall, Não um Sistema de Memória

pip install auto-memory

~1.900 linhas de Python. Zero dependências. Instalado em 30 segundos.

Em vez de inundar o contexto com resultados grep, você dá ao agente acesso cirúrgico ao que realmente importa — 50 tokens em vez de 10.000.

Conclusão

Context rot é uma restrição arquitetural real. auto-memory contorna isso dando ao seu agente um mecanismo de recall barato e preciso.

Confira: auto-memory no GitHub. Post original de Desi Villanueva: I Wasted 68 Minutes a Day.

Foundry Toolboxes: Um único endpoint para todas as ferramentas dos seus agentes

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

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

Aqui está um problema que parece chato até você vivenciá-lo: sua organização está construindo múltiplos agentes IA, cada um precisa de ferramentas, e cada time as configura do zero. A mesma integração de busca web, a mesma config do Azure AI Search, a mesma conexão com o servidor MCP do GitHub — mas em outro repositório, por outro time, com outras credenciais e sem governança compartilhada.

A Microsoft Foundry acabou de lançar Toolboxes em preview pública, e é uma resposta direta a esse problema.

O que é um Toolbox?

Um Toolbox é um bundle de ferramentas nomeado e reutilizável, definido uma vez no Foundry e exposto por meio de um único endpoint compatível com MCP. Qualquer runtime de agente que fale MCP pode consumi-lo — sem lock-in no Foundry Agents.

A proposta é simples: build once, consume anywhere. Defina as ferramentas, configure a autenticação de forma centralizada (OAuth passthrough, identidade gerenciada do Entra), publique o endpoint. Cada agente que precisar dessas ferramentas se conecta ao endpoint e as obtém todas.

Os quatro pilares (dois disponíveis hoje)

Pilar	Status	O que faz
Discover	Em breve	Encontra ferramentas aprovadas sem busca manual
Build	Disponível	Agrupa ferramentas em um bundle reutilizável
Consume	Disponível	Um endpoint MCP único expõe todas as ferramentas
Govern	Em breve	Auth centralizada + observabilidade em todas as chamadas

Exemplo prático

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Buscar documentação e responder a issues do GitHub.",
 tools=[
 {"type": "web_search", "description": "Buscar documentação pública"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Após a publicação, o Foundry fornece um endpoint unificado. Uma conexão, todas as ferramentas.

Sem lock-in no Foundry Agents

Os Toolboxes são criados e gerenciados no Foundry, mas a superfície de consumo é o protocolo MCP aberto. Você pode usá-los de agentes personalizados com Microsoft Agent Framework ou LangGraph, GitHub Copilot e outros IDEs compatíveis com MCP.

Por que importa agora

A onda multi-agentes está chegando à produção. Cada novo agente é uma nova superfície para configuração duplicada, credenciais desatualizadas e comportamento inconsistente. A base Build + Consume é suficiente para começar a centralizar. Quando o pilar Govern chegar, você terá uma camada de ferramentas observável e controlada centralmente para toda a sua frota de agentes.

Conclusão

Ainda é cedo — preview pública, SDK Python primeiro, com Discover e Govern ainda por vir. Mas o modelo é sólido e o design nativo de MCP significa que funciona com as ferramentas que você já está construindo. Confira o anúncio oficial para começar.

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.

Atualize Agora: .NET 10.0.7 Atualização de Segurança OOB para ASP.NET Core Data Protection

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

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

Esta atualização não é opcional. Se sua aplicação usa Microsoft.AspNetCore.DataProtection, você precisa atualizar para 10.0.7.

O Que Aconteceu

Após o lançamento Patch Tuesday .NET 10.0.6, usuários reportaram falhas na descriptografia. Durante a investigação, a equipe descobriu o CVE-2026-40372: o tag de validação HMAC era calculado sobre os bytes errados, podendo resultar em elevação de privilégios.

Como Corrigir

dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7

Depois reconstrua e reimplante sua aplicação.

Anúncio original de Rahul Bhandari: .NET 10.0.7 Out-of-Band Security Update.

azd + GitHub Copilot: Configuração de projeto com IA e resolução inteligente de erros

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Você conhece aquele momento em que quer fazer o deploy de uma app existente no Azure e se vê olhando para um azure.yaml em branco, tentando lembrar se sua API Express deveria usar Container Apps ou App Service? Esse momento acabou de ficar muito mais curto.

O Azure Developer CLI (azd) agora se integra com o GitHub Copilot de duas formas concretas: scaffolding assistido por IA durante o azd init, e resolução inteligente de erros quando os deploys falham. Ambas as funcionalidades ficam completamente no terminal — exatamente onde eu quero que estejam.

Configuração com Copilot durante azd init

Quando você executa azd init, agora aparece a opção “Set up with GitHub Copilot (Preview)”. Selecione-a e o Copilot analisa sua base de código para gerar o azure.yaml, os templates de infraestrutura e os módulos Bicep — com base no seu código real.

azd init
# Selecione: "Set up with GitHub Copilot (Preview)"

Pré-requisitos:

azd 1.23.11 ou superior — verifique com azd version ou atualize com azd update
Assinatura ativa do GitHub Copilot (Individual, Business ou Enterprise)
GitHub CLI (gh) — o azd pedirá login se necessário

O que acho genuinamente útil: funciona nos dois sentidos. Construindo do zero? O Copilot ajuda a configurar os serviços Azure certos desde o início. Tem uma app existente que você queria fazer deploy faz tempo? Aponte o Copilot para ela e ele gera a configuração sem você precisar reestruturar nada.

O que ele faz de verdade

Digamos que você tem uma API Express em Node.js com dependência do PostgreSQL. Em vez de decidir manualmente entre Container Apps e App Service, e depois escrever Bicep do zero, o Copilot detecta sua stack e gera:

Um azure.yaml com as configurações corretas de language, host e build
Um módulo Bicep para Azure Container Apps
Um módulo Bicep para Azure Database for PostgreSQL

E ele faz verificações prévias antes de tocar em qualquer coisa — verifica se seu diretório git está limpo, pede consentimento para as ferramentas do servidor MCP. Nada acontece sem que você saiba exatamente o que vai mudar.

Resolução de erros com Copilot

Erros de deploy são inevitáveis. Parâmetros faltando, problemas de permissão, disponibilidade de SKUs — e a mensagem de erro raramente diz a única coisa que você realmente precisa saber: como resolver.

Sem Copilot, o ciclo é: copiar o erro → pesquisar na documentação → ler três respostas irrelevantes do Stack Overflow → executar alguns comandos az CLI → tentar de novo e torcer. Com o Copilot integrado ao azd, esse ciclo colapsa. Quando qualquer comando azd falha, ele imediatamente oferece quatro opções:

Explain — descrição em linguagem natural do que deu errado
Guidance — instruções passo a passo para corrigir
Diagnose and Guide — análise completa + Copilot aplica a correção (com sua aprovação) + nova tentativa opcional
Skip — resolver você mesmo

O ponto crucial: o Copilot já tem contexto sobre seu projeto, o comando que falhou e a saída do erro. Suas sugestões são específicas para sua situação, não documentação genérica.

Configurar comportamento padrão

Se você sempre escolhe a mesma opção, pule o prompt interativo:

azd config set copilot.errorHandling.category troubleshoot

Valores: explain, guidance, troubleshoot, fix, skip. Você também pode habilitar auto-fix e retry:

azd config set copilot.errorHandling.fix allow

Voltar ao modo interativo a qualquer momento:

azd config unset copilot.errorHandling.category

Conclusão

Esta é exatamente o tipo de integração do Copilot que agrega valor real. Experimente executando azd update para obter a versão mais recente e use azd init no seu próximo projeto.

Leia o anúncio original aqui.

Escrevendo addons nativos Node.js em C# com .NET Native AOT

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Um cenário que adoro: um time que trabalha com ferramentas .NET tinha addons nativos do Node.js escritos em C++ e compilados via node-gyp. Funcionava. Mas exigia Python instalado na máquina de cada desenvolvedor — uma versão antiga de Python, diga-se — só para construir um pacote que ninguém no time tocaria diretamente.

Então fizeram uma pergunta muito razoável: já temos o SDK do .NET instalado, por que estamos escrevendo C++?

A resposta foi Native AOT, e o resultado é genuinamente elegante.

A ideia básica

Um addon nativo do Node.js é uma biblioteca compartilhada (.dll no Windows, .so no Linux, .dylib no macOS) que o Node.js pode carregar em tempo de execução. A interface se chama N-API — uma API C estável e compatível com ABI. A N-API não se importa com que linguagem produziu a biblioteca, só que ela exporte os símbolos certos.

O .NET Native AOT pode produzir exatamente isso. Ele compila o código C# ahead-of-time em uma biblioteca nativa compartilhada com pontos de entrada arbitrários. Esse é todo o truque.

Configuração do projeto

O arquivo de projeto é mínimo:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot diz ao SDK para produzir uma biblioteca compartilhada no dotnet publish. AllowUnsafeBlocks é necessário para o interop com N-API usando ponteiros de função e buffers fixos.

Exportar o ponto de entrada

O Node.js espera que sua biblioteca exporte napi_register_module_v1. Em C#, [UnmanagedCallersOnly] faz exatamente isso:

public static unsafe partial class RegistryAddon
{
 [UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
 public static nint Init(nint env, nint exports)
 {
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
 }
}

Coisas que valem destaque: nint é um inteiro de tamanho nativo — o equivalente gerenciado de intptr_t. O sufixo u8 produz um ReadOnlySpan<byte> com um literal de string UTF-8, passado diretamente para a N-API sem nenhuma alocação de codificação. E [UnmanagedCallersOnly] exporta o método com exatamente o nome do ponto de entrada que o Node.js procura.

Resolver N-API contra o processo host

As funções N-API são exportadas pelo próprio node.exe, não por uma biblioteca separada. Então, em vez de linkar contra algo, você as resolve contra o processo em execução na inicialização:

private static void Initialize()
{
 NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

 static nint ResolveDllImport(
 string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
 {
 if (libraryName is not "node") return 0;
 return NativeLibrary.GetMainProgramHandle();
 }
}

Com isso, as declarações P/Invoke funcionam corretamente com [LibraryImport] e marshalling gerado por código-fonte.

Uma função exportada real

Aqui está o leitor de registro que construíram:

[UnmanagedCallersOnly(CallConvs = [typeof(CallConvCdecl)])]
private static nint ReadStringValue(nint env, nint info)
{
 try
 {
 var keyPath = GetStringArg(env, info, 0);
 var valueName = GetStringArg(env, info, 1);

 if (keyPath is null || valueName is null)
 {
 ThrowError(env, "Expected two string arguments: keyPath, valueName");
 return 0;
 }

 using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);

 return key?.GetValue(valueName) is string value
 ? CreateString(env, value)
 : GetUndefined(env);
 }
 catch (Exception ex)
 {
 ThrowError(env, $"Registry read failed: {ex.Message}");
 return 0;
 }
}

Nota importante sobre o try/catch: uma exceção não tratada em um método [UnmanagedCallersOnly] derruba o processo host. Sempre capture e encaminhe ao JavaScript via ThrowError.

Chamando a partir do TypeScript

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;
const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk', 'InstallLocation');

TypeScript → C#, sem Python, sem C++.

O que ganharam

A vitória imediata foi na experiência do contribuidor: nenhuma versão específica de Python necessária, yarn install funciona com apenas Node.js e o SDK do .NET. Pipelines de CI também ficaram mais simples. A performance foi comparável à implementação em C++.

Conclusão

O time do C# Dev Kit substituiu a sobrecarga Python/C++ por código C# limpo que todo o time já sabe escrever e depurar. Para o walkthrough completo com todos os helpers de marshalling de strings, veja o artigo original no blog .NET.

VS Code 1.117: Os Agentes Estão Ganhando Suas Próprias Branches Git e Eu Tô Adorando

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

A linha entre “assistente de IA” e “colega de equipe de IA” continua ficando mais fina. O VS Code 1.117 acabou de sair e as notas de versão completas estão recheadas, mas a história é clara: os agentes estão se tornando cidadãos de primeira classe no seu fluxo de trabalho de desenvolvimento.

Aqui está o que realmente importa.

O modo Autopilot finalmente lembra sua preferência

Antes, você tinha que reativar o Autopilot toda vez que iniciava uma nova sessão. Irritante. Agora seu modo de permissão persiste entre sessões, e você pode configurar o padrão.

O Agent Host suporta três configurações de sessão:

Default — as ferramentas pedem confirmação antes de executar
Bypass — aprova tudo automaticamente
Autopilot — totalmente autônomo, responde suas próprias perguntas e segue em frente

Se você está montando um novo projeto .NET com migrations, Docker e CI — configure para Autopilot uma vez e esqueça. Essa preferência fica salva.

Worktree e isolamento git para sessões de agentes

Essa é a grande novidade. Sessões de agentes agora suportam isolamento completo com worktree e git. Isso significa que quando um agente trabalha em uma tarefa, ele ganha sua própria branch e diretório de trabalho. Sua branch principal fica intocada.

Melhor ainda — o Copilot CLI gera nomes de branch significativos para essas sessões de worktree. Chega de agent-session-abc123. Você recebe algo que realmente descreve o que o agente está fazendo.

Para desenvolvedores .NET que gerenciam múltiplas branches de features ou corrigem bugs enquanto uma tarefa longa de scaffolding roda, isso é um divisor de águas. Você pode ter um agente construindo seus controllers de API em um worktree enquanto você depura um problema na camada de serviços em outro. Sem conflitos. Sem stashing. Sem bagunça.

Subagentes e equipes de agentes

O Agent Host Protocol agora suporta subagentes. Um agente pode criar outros agentes para lidar com partes de uma tarefa. Pense nisso como delegar — seu agente principal coordena, e agentes especializados cuidam das partes.

Isso é cedo, mas o potencial para fluxos de trabalho .NET é óbvio. Imagine um agente cuidando das suas migrations do EF Core enquanto outro configura seus testes de integração. Ainda não chegamos totalmente lá, mas o suporte ao protocolo chegando agora significa que as ferramentas virão rápido.

Saída do terminal incluída automaticamente quando agentes enviam input

Pequeno mas significativo. Quando um agente envia input para o terminal, a saída do terminal agora é automaticamente incluída no contexto. Antes, o agente precisava de um turno extra só para ler o que aconteceu.

Se você já viu um agente executar dotnet build, falhar, e depois precisar de mais uma ida e volta só para ver o erro — essa fricção acabou. Ele vê a saída imediatamente e reage.

O app Agents no macOS se atualiza sozinho

O app independente Agents no macOS agora se atualiza sozinho. Chega de baixar novas versões manualmente. Ele simplesmente se mantém atualizado.

As coisas menores que vale a pena saber

Os hovers do package.json agora mostram tanto a versão instalada quanto a última disponível. Útil se você gerencia ferramentas npm junto com seus projetos .NET.
Imagens em comentários JSDoc são renderizadas corretamente em hovers e completions.
Sessões do Copilot CLI agora indicam se foram criadas pelo VS Code ou externamente — prático quando você está pulando entre terminais.
Copilot CLI, Claude Code e Gemini CLI são reconhecidos como tipos de shell. O editor sabe o que você está executando.

A conclusão

VS Code 1.117 não é um despejo de features chamativas. É infraestrutura. Isolamento com worktree, permissões persistentes, protocolos de subagentes — esses são os blocos de construção para um fluxo de trabalho onde agentes lidam com tarefas reais e paralelas sem pisar no seu código.

Se você está construindo com .NET e ainda não mergulhou no fluxo de trabalho com agentes, honestamente, agora é a hora de começar.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 acontece em 18 de abril de 2026 no Kinépolis Diversia em Alcobendas, Madri. É o maior evento comunitário Azure da Espanha, reunindo 38 palestrantes em 3 trilhas paralelas cobrindo agentes de IA, redes Azure, Cosmos DB, Fabric, IoT, segurança e muito mais.

O evento vai das 08:30 às 18:30 e inclui keynote, intervalos para café, almoço e uma sessão de encerramento com perguntas.

Destaques da agenda

Domando Agentes de IA: governança, ferramentas e APIs com Azure AI Foundry e Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: sistemas multi-agente em ação
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Ingressos

A inscrição é uma doação simbólica — o valor total do ingresso vai diretamente para a Plan International, apoiando os direitos das crianças e a igualdade no mundo. Capacidade limitada, então garanta seu lugar cedo.

Azure Tour 2026

Além de Madri, o Global Azure Tour 2026 também inclui paradas em Zaragoza, Tenerife e Sevilha.

O RFT do Foundry ficou mais barato e inteligente — Veja o que mudou

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

Se você está desenvolvendo aplicações .NET que dependem de modelos fine-tunados, as atualizações do Foundry deste mês merecem sua atenção. O Reinforcement Fine-Tuning ficou mais acessível e significativamente mais barato.

Os detalhes completos estão no anúncio oficial, mas aqui vai o resumo prático.

Treinamento Global para o4-mini

o4-mini é o modelo preferido para cargas de trabalho pesadas em raciocínio e agentes. A grande novidade: agora você pode iniciar jobs de fine-tuning a partir de mais de 13 regiões Azure com taxas de treinamento por token mais baixas em comparação com o treinamento Standard. Mesma infraestrutura, mesma qualidade, maior alcance.

Se sua equipe está distribuída geograficamente, isso importa. Você não está mais preso a um punhado de regiões para treinar.

Aqui está a chamada da API REST para iniciar um job de treinamento global:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

Essa flag trainingType: globalstandard é a diferença chave.

Novos Avaliadores de Modelo: Família GPT-4.1

Avaliadores definem o sinal de recompensa contra o qual seu modelo otimiza. Até agora, avaliadores baseados em modelo eram limitados a um conjunto menor de modelos. Agora você tem três novas opções: GPT-4.1, GPT-4.1-mini e GPT-4.1-nano.

Quando você deve usar avaliadores de modelo em vez de determinísticos? Quando a saída da sua tarefa é aberta, quando você precisa de pontuação parcial em múltiplas dimensões, ou quando está construindo workflows com agentes onde a correção das chamadas de ferramentas depende do contexto semântico.

A questão é que a estratégia de níveis é prática:

GPT-4.1-nano para iterações iniciais. Baixo custo, ciclos de feedback rápidos.
GPT-4.1-mini quando sua rubrica de avaliação estiver estável e você precisar de maior fidelidade.
GPT-4.1 para avaliação em produção ou rubricas complexas onde cada decisão de pontuação conta.

Você pode até misturar tipos de avaliadores em um único job de RFT. Use string-match para a dimensão de “resposta correta” e um avaliador de modelo para avaliar a qualidade do raciocínio. Essa flexibilidade é honestamente o que torna isso útil para cargas de trabalho reais.

A Pegadinha do Formato de Dados do RFT

Isso confunde muita gente. O formato de dados do RFT é diferente do SFT. A última mensagem em cada linha deve ter o papel User ou Developer — não Assistant. A resposta esperada vai em uma chave de nível superior como reference_answer que o avaliador referencia diretamente.

Se você estava fazendo supervised fine-tuning e quer mudar para RFT, precisa reestruturar seus dados de treinamento. Não pule essa etapa ou seus jobs vão falhar silenciosamente.

Por Que Isso Importa para Desenvolvedores .NET

Se você está chamando modelos fine-tunados nas suas aplicações .NET através do SDK Azure OpenAI, treinamento mais barato significa que você pode iterar de forma mais agressiva. As opções de avaliadores de modelo significam que você pode fazer fine-tuning para tarefas com nuances — não apenas cenários de correspondência exata. E o guia de boas práticas no GitHub vai te poupar tempo real de debugging.

Comece pequeno. Dez a cem amostras. Avaliador simples. Valide o ciclo. Depois escale.

Seus experimentos de IA no Azure estão queimando dinheiro — Veja como resolver isso

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

Se você está construindo apps com IA no Azure agora, provavelmente já notou algo: sua fatura da nuvem está diferente do que costumava ser. Não apenas mais alta — mais estranha. Com picos. Difícil de prever.

A Microsoft acabou de publicar um ótimo artigo sobre princípios de otimização de custos na nuvem que ainda importam, e honestamente, o timing não poderia ser melhor. Porque as cargas de trabalho de IA mudaram o jogo quando se trata de custos.

Por que cargas de trabalho de IA são diferentes

A questão é a seguinte. Cargas de trabalho tradicionais de .NET são relativamente previsíveis. Você conhece seu tier de App Service, conhece seus DTUs de SQL, consegue estimar o gasto mensal com bastante precisão. Cargas de trabalho de IA? Nem tanto.

Você está testando múltiplos modelos para ver qual se encaixa. Está subindo infraestrutura com GPU para fine-tuning. Está fazendo chamadas de API para o Azure OpenAI onde o consumo de tokens varia enormemente dependendo do tamanho do prompt e do comportamento do usuário. Cada experimento custa dinheiro real, e você pode executar dezenas antes de encontrar a abordagem certa.

Essa imprevisibilidade é o que torna a otimização de custos crítica — não como algo secundário, mas desde o primeiro dia.

Gerenciamento vs. otimização — saiba a diferença

Uma distinção do artigo que acho que os desenvolvedores ignoram: há uma diferença entre gerenciamento de custos e otimização de custos.

Gerenciamento é rastreamento e relatórios. Você configura orçamentos no Azure Cost Management, recebe alertas, vê dashboards. Isso é o básico.

Otimização é onde você realmente toma decisões. Você realmente precisa daquele tier S3, ou o S1 daria conta da sua carga? Aquela instância de compute sempre ligada está ociosa nos finais de semana? Você poderia usar instâncias spot para seus jobs de treinamento?

Como desenvolvedores .NET, tendemos a focar no código e deixar as decisões de infraestrutura para “o time de operações”. Mas se você está fazendo deploy no Azure, essas decisões também são suas.

O que realmente funciona

Com base no artigo e na minha própria experiência, é isso que faz a diferença:

Saiba o que está gastando e onde. Tagueie seus recursos. Sério. Se você não consegue identificar qual projeto ou experimento está consumindo seu orçamento, não consegue otimizar nada. Azure Cost Management com tagging adequado é seu melhor amigo.

Estabeleça limites antes de experimentar. Use Azure Policy para restringir SKUs caros em ambientes de dev/test. Defina limites de gasto nos seus deployments do Azure OpenAI. Não espere a fatura chegar para perceber que alguém deixou um cluster de GPU rodando no final de semana.

Redimensione continuamente. Aquela VM que você escolheu durante a prototipação? Provavelmente está errada para produção. O Azure Advisor dá recomendações — realmente olhe para elas. Revise mensalmente, não anualmente.

Pense no ciclo de vida. Recursos de desenvolvimento devem ser desligados. Ambientes de teste não precisam rodar 24/7. Use políticas de desligamento automático. Para cargas de trabalho de IA especificamente, considere opções serverless onde você paga por execução em vez de manter o compute ligado.

Meça o valor, não apenas o custo. Essa é fácil de esquecer. Um modelo que custa mais mas entrega resultados significativamente melhores pode ser a decisão certa. O objetivo não é gastar o mínimo — é gastar de forma inteligente.

A conclusão

Otimização de custos na nuvem não é uma limpeza pontual. É um hábito. E com cargas de trabalho de IA tornando os gastos menos previsíveis do que nunca, construir esse hábito cedo te poupa de surpresas dolorosas depois.

Se você é um desenvolvedor .NET construindo no Azure, comece a tratar sua fatura da nuvem como trata seu código — revise regularmente, refatore quando ficar bagunçado, e nunca faça deploy sem entender quanto vai custar.

Docker Sandbox permite que agentes do Copilot refatorem seu código sem colocar sua máquina em risco

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

Se você já usou o modo agente do Copilot para algo além de edições pequenas, conhece a dor. Cada escrita de arquivo, cada comando no terminal — mais um prompt de permissão. Agora imagina isso em 50 projetos. Nada divertido.

O time do Azure acabou de publicar um post sobre Docker Sandbox para agentes do GitHub Copilot, e honestamente, essa é uma das melhorias mais práticas que eu já vi em ferramentas agênticas. Usa microVMs para dar ao Copilot um ambiente completamente isolado onde ele pode fazer de tudo — instalar pacotes, rodar builds, executar testes — sem tocar no seu sistema host.

O que o Docker Sandbox realmente te oferece

A ideia central é simples: subir uma microVM leve com um ambiente Linux completo, sincronizar seu workspace para dentro dela, e deixar o agente do Copilot operar livremente lá dentro. Quando termina, as mudanças são sincronizadas de volta.

Eis o que faz isso ser mais do que simplesmente “rodar coisas num container”:

Sincronização bidirecional do workspace que preserva caminhos absolutos. A estrutura do seu projeto fica idêntica dentro do sandbox. Sem falhas de build por causa de caminhos.
Docker daemon privado rodando dentro da microVM. O agente pode construir e rodar containers sem nunca montar o socket Docker do seu host. Isso é muito importante para segurança.
Proxies de filtragem HTTP/HTTPS que controlam o que o agente pode acessar na rede. Você decide quais registries e endpoints são permitidos. Ataques à cadeia de suprimentos por um npm install malicioso dentro do sandbox? Bloqueados.
Modo YOLO — sim, é assim que eles chamam. O agente roda sem prompts de permissão porque literalmente não consegue danificar seu host. Toda ação destrutiva está contida.

Por que desenvolvedores .NET deveriam se importar

Pense no trabalho de modernização que tantos times estão enfrentando agora. Você tem uma solução .NET Framework com 30 projetos e precisa migrá-la para .NET 9. São centenas de alterações de arquivos — arquivos de projeto, atualizações de namespaces, substituições de API, migrações de NuGet.

Com Docker Sandbox, você pode apontar um agente do Copilot para um projeto, deixá-lo refatorar livremente dentro da microVM, rodar dotnet build e dotnet test para validar, e só aceitar as mudanças que realmente funcionam. Sem risco dele acidentalmente destruir seu ambiente de desenvolvimento local enquanto experimenta.

O post também descreve rodar uma frota de agentes em paralelo — cada um no seu próprio sandbox — trabalhando em diferentes projetos simultaneamente. Para soluções .NET grandes ou arquiteturas de microsserviços, isso economiza uma quantidade enorme de tempo. Um agente por serviço, todos rodando isolados, todos validados independentemente.

O ângulo da segurança importa

Aqui está o que a maioria das pessoas ignora: quando você deixa um agente de IA executar comandos arbitrários, está confiando a ele toda a sua máquina. Docker Sandbox inverte esse modelo. O agente recebe autonomia total dentro de um ambiente descartável. O proxy de rede garante que ele só pode baixar de fontes aprovadas. Seu filesystem host, Docker daemon e credenciais ficam intocados.

Para times com requisitos de compliance — e isso é a maioria das empresas .NET — essa é a diferença entre “não podemos usar IA agêntica” e “podemos adotá-la com segurança.”

Conclusão

Docker Sandbox resolve a tensão fundamental da programação agêntica: agentes precisam de liberdade para serem úteis, mas liberdade na sua máquina host é perigoso. MicroVMs te dão os dois. Se você está planejando qualquer refatoração ou modernização .NET em larga escala, vale a pena configurar isso agora. A combinação da inteligência de código do Copilot com um ambiente de execução seguro é exatamente o que times de produção estavam esperando.

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.

As ferramentas Azure MCP agora vêm integradas no Visual Studio 2022 — Sem extensão necessária

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

Se você tem usado as ferramentas Azure MCP no Visual Studio através da extensão separada, já conhece o processo — instalar o VSIX, reiniciar, torcer para não quebrar, gerenciar incompatibilidades de versão. Essa fricção acabou.

Yun Jung Choi anunciou que as ferramentas Azure MCP agora são distribuídas diretamente como parte da carga de trabalho de desenvolvimento Azure no Visual Studio 2022. Sem extensão. Sem VSIX. Sem a dança do reiniciar.

O que isso realmente significa

A partir do Visual Studio 2022 versão 17.14.30, o Azure MCP Server vem incluído na carga de trabalho de desenvolvimento Azure. Se você já tem essa carga de trabalho instalada, basta ativá-lo no GitHub Copilot Chat e pronto.

Mais de 230 ferramentas em 45 serviços Azure — acessíveis diretamente pela janela de chat. Liste suas contas de armazenamento, faça deploy de uma app ASP.NET Core, diagnostique problemas no App Service, consulte o Log Analytics — tudo sem abrir uma aba do navegador.

Por que isso importa mais do que parece

A questão com ferramentas de desenvolvimento é a seguinte: cada passo extra é fricção, e fricção mata a adoção. Ter o MCP como extensão separada significava incompatibilidades de versão, falhas na instalação e mais uma coisa para manter atualizada. Integrá-lo na carga de trabalho significa:

Um único caminho de atualização pelo Visual Studio Installer
Sem divergência de versões entre a extensão e a IDE
Sempre atualizado — o MCP Server é atualizado com os releases regulares do VS

Para equipes que padronizam no Azure, isso é muito relevante. Você instala a carga de trabalho uma vez, ativa as ferramentas, e elas estão lá para cada sessão.

O que você pode fazer com isso

As ferramentas cobrem todo o ciclo de vida do desenvolvimento através do Copilot Chat:

Aprender — pergunte sobre serviços Azure, boas práticas, padrões de arquitetura
Projetar e desenvolver — obtenha recomendações de serviços, configure o código da sua aplicação
Fazer deploy — provisione recursos e faça deploy diretamente pela IDE
Solucionar problemas — consulte logs, verifique a saúde dos recursos, diagnostique problemas em produção

Um exemplo rápido — digite isso no Copilot Chat:

List my storage accounts in my current subscription.

O Copilot chama as ferramentas Azure MCP por trás dos panos, consulta suas assinaturas e retorna uma lista formatada com nomes, localizações e SKUs. Sem precisar do portal.

Como ativar

Atualize para o Visual Studio 2022 17.14.30 ou superior
Certifique-se de que a carga de trabalho Azure development está instalada
Abra o GitHub Copilot Chat
Clique no botão Select tools (o ícone das duas chaves)
Ative o Azure MCP Server

É isso. Fica ativado entre sessões.

Um detalhe

As ferramentas vêm desativadas por padrão — você precisa ativá-las manualmente. E as ferramentas específicas do VS 2026 não estão disponíveis no VS 2022. A disponibilidade das ferramentas também depende das permissões da sua assinatura Azure, assim como no portal.

O cenário geral

Isso faz parte de uma tendência clara: o MCP está se tornando o padrão para expor ferramentas de nuvem nas IDEs de desenvolvimento. Já vimos o lançamento estável do Azure MCP Server 2.0 e integrações MCP no VS Code e em outros editores. Tê-lo integrado no sistema de cargas de trabalho do Visual Studio é a evolução natural.

Para nós desenvolvedores .NET que vivemos no Visual Studio, isso elimina mais um motivo para trocar de contexto para o portal Azure. E sinceramente, quanto menos troca de abas, melhor.

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.

Aspire 13.2 ganha MongoDB EF Core e Azure Data Lake — Duas integrações que vale a pena experimentar

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

Aspire 13.2 acabou de chegar com duas novas integrações de banco de dados que merecem sua atenção: MongoDB Entity Framework Core e Azure Data Lake Storage. Se você queria usar EF Core com MongoDB em uma app Aspire, ou precisava conectar workloads de data lake com service discovery, esta versão entrega as duas coisas.

MongoDB encontra EF Core no Aspire

Essa é a que mais me empolga. O Aspire já suportava MongoDB há um tempo, mas sempre foi com o driver direto — sem EF Core, sem DbContext, sem consultas LINQ nos seus documentos. Agora você tem a experiência completa do EF Core com MongoDB, mais os health checks automáticos e o service discovery do Aspire.

A configuração segue o padrão típico do Aspire. No seu AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Depois no seu projeto consumidor, adicione a integração EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

E registre seu DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

A partir daí, é EF Core padrão. Defina suas entidades, use seu DbContext como faria com qualquer outro provider. A integração cuida do connection pooling, traces OpenTelemetry e health checks nos bastidores.

Para desenvolvedores .NET que estavam usando MongoDB com o driver direto e configurando connection strings manualmente, essa é uma ótima melhoria. Você ganha a abstração completa do EF Core sem perder o service discovery do Aspire.

Azure Data Lake Storage entra na jogada

A segunda grande adição é uma integração Azure Data Lake Storage (ADLS). Se você está construindo pipelines de dados, processos ETL ou plataformas de analytics, agora pode conectar recursos de Data Lake da mesma forma que conectaria qualquer outra dependência do Aspire.

No AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

No projeto consumidor:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Sem gerenciamento manual de connection strings, sem caçar credenciais. O Aspire provisiona os recursos e os injeta. Para quem constrói apps .NET cloud-native que lidam tanto com dados operacionais quanto com workloads analíticos, isso faz o data lake parecer um cidadão de primeira classe no modelo do Aspire.

As pequenas correções que importam

Além das funcionalidades principais, há algumas melhorias que valem a menção:

Correção do connection string do MongoDB — a barra antes do nome do banco de dados agora é tratada corretamente. Se você tinha um workaround, pode removê-lo
Exports do SQL Server — Aspire.Hosting.SqlServer agora exporta opções adicionais de configuração do servidor para um controle mais granular
Atualizações de emuladores — emulador do ServiceBus 2.0.0, emulador do App Configuration 1.0.2, e o emulador preview do CosmosDB agora inclui uma verificação de disponibilidade
Azure Managed Redis — agora usa rediss:// (Redis Secure) por padrão, então as conexões são criptografadas desde o início

Essa última é sutil mas importante — Redis criptografado por padrão significa uma coisa a menos para configurar em produção.

Concluindo

Aspire 13.2 é uma versão incremental, mas as integrações de MongoDB EF Core e Data Lake preenchem lacunas reais. Se você estava esperando suporte adequado de EF Core com MongoDB no Aspire, ou precisava do Data Lake como dependência de primeira classe, atualize para a 13.2 e teste. O comando aspire add gera tudo o que você precisa.

Leia as notas de versão completas para mais detalhes, e confira a galeria de integrações para a lista completa.

azd update — Um único comando para todos os seus gerenciadores de pacotes

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

Sabe aquela mensagem “Uma nova versão do azd está disponível” que aparece a cada poucas semanas? Aquela que você ignora porque não lembra se instalou o azd via winget, Homebrew ou aquele script curl que rodou há seis meses? Pois é, isso finalmente foi resolvido.

A Microsoft acabou de lançar o azd update — um único comando que atualiza o Azure Developer CLI para a versão mais recente, independentemente de como você o instalou originalmente. Windows, macOS, Linux — não importa. Um comando só.

Como funciona

azd update

É isso. Se você quer acesso antecipado a novas funcionalidades, pode mudar para o build diário de insiders:

azd update --channel daily
azd update --channel stable

O comando detecta seu método de instalação atual e usa o mecanismo de atualização apropriado por baixo dos panos. Chega de “espera, eu usei winget ou choco nessa máquina?”

O pequeno detalhe

azd update está disponível a partir da versão 1.23.x. Se você está em uma versão anterior, vai precisar fazer uma última atualização manual usando seu método de instalação original. Depois disso, o azd update cuida de tudo dali em diante.

Verifique sua versão atual com azd version. Se precisar de uma instalação do zero, a documentação de instalação te ajuda.

Por que isso importa

É uma pequena melhoria de qualidade de vida, mas para quem usa azd diariamente para fazer deploy de agentes de IA e apps Aspire no Azure, estar atualizado significa menos momentos de “esse bug já tinha sido corrigido na última versão”. Uma coisa a menos para se preocupar.

Leia o anúncio completo e a análise mais detalhada do Jon Gallant para mais contexto.

Azure DevOps Server Patch Abril 2026 — Correção na Conclusão de PRs e Atualizações de Segurança

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

Aviso rápido para equipes que rodam Azure DevOps Server auto-hospedado: a Microsoft lançou o Patch 3 de abril 2026 com três correções direcionadas.

O que foi corrigido

Falhas na conclusão de pull requests — uma exceção de referência nula durante o auto-completamento de work items podia causar falhas nos merges de PRs. Se você encontrou erros aleatórios na conclusão de PRs, essa é provavelmente a causa
Validação de redirecionamento no logout — validação aprimorada durante o logout para prevenir possíveis redirecionamentos maliciosos. Essa é uma correção de segurança que vale a pena aplicar logo
Conexões PAT com GitHub Enterprise Server — a criação de conexões por Personal Access Token com o GitHub Enterprise Server estava quebrada, agora foi restaurada

Como atualizar

Baixe o Patch 3 e execute o instalador. Para verificar se o patch foi aplicado:

<patch-installer>.exe CheckInstall

Se você roda Azure DevOps Server on-premises, a Microsoft recomenda fortemente manter-se no patch mais recente tanto por segurança quanto por confiabilidade. Confira as notas de versão para todos os detalhes.

Azure Smart Tier em GA — Otimização automática de custos no Blob Storage sem regras de ciclo de vida

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

Se você já passou tempo ajustando as políticas de ciclo de vida do Azure Blob Storage e depois viu tudo desmoronar quando os padrões de acesso mudaram, isso aqui é para você. A Microsoft acabou de anunciar a disponibilidade geral do smart tier para Azure Blob e Data Lake Storage — uma capacidade de tiering totalmente gerenciada que move objetos automaticamente entre os níveis hot, cool e cold com base no uso real.

O que o smart tier realmente faz

O conceito é direto: o smart tier avalia continuamente o último horário de acesso de cada objeto na sua conta de armazenamento. Dados acessados frequentemente ficam em hot, dados inativos passam para cool após 30 dias, e depois para cold após mais 60 dias. Quando os dados são acessados novamente, são promovidos de volta para hot imediatamente. O ciclo recomeça.

Sem regras de ciclo de vida para configurar. Sem previsões de padrões de acesso. Sem ajustes manuais.

Durante a preview, a Microsoft reportou que mais de 50% da capacidade gerenciada pelo smart tier foi automaticamente movida para níveis mais frios com base nos padrões reais de acesso. É uma redução de custos significativa para contas de armazenamento grandes.

Por que isso importa para desenvolvedores .NET

Se você está construindo aplicações que geram logs, telemetria, dados analíticos, ou qualquer tipo de patrimônio de dados em crescimento — e sejamos honestos, quem não está? — os custos de armazenamento se acumulam rápido. A abordagem tradicional era escrever políticas de gerenciamento de ciclo de vida, testá-las e depois reajustá-las quando os padrões de acesso da sua aplicação mudavam. O smart tier elimina todo esse fluxo de trabalho.

Alguns cenários práticos onde isso ajuda:

Telemetria e logs de aplicações — hot durante a depuração, raramente acessados depois de algumas semanas
Pipelines de dados e saídas de ETL — acessados intensamente durante o processamento, depois majoritariamente cold
Conteúdo gerado por usuários — uploads recentes ficam em hot, conteúdo mais antigo esfria gradualmente
Dados de backup e arquivamento — acessados ocasionalmente para conformidade, na maioria das vezes inativos

Como configurar

Habilitar o smart tier é uma configuração única:

Contas novas: Selecione smart tier como o nível de acesso padrão durante a criação da conta de armazenamento (redundância zonal necessária)
Contas existentes: Mude o nível de acesso de blob da sua configuração padrão atual para smart tier

Objetos menores que 128 KiB ficam em hot e não geram a taxa de monitoramento. Para todo o resto, você paga as taxas padrão de capacidade hot/cool/cold sem cobranças de transição de nível, sem penalidades de exclusão antecipada e sem custos de recuperação de dados. Uma taxa mensal de monitoramento por objeto cobre a orquestração.

O trade-off que você precisa conhecer

As regras de tiering do smart tier são estáticas (30 dias → cool, 90 dias → cold). Se você precisa de limites personalizados — digamos, mover para cool após 7 dias para uma carga de trabalho específica — as regras de ciclo de vida continuam sendo o caminho. E não misture os dois: evite usar regras de ciclo de vida em objetos gerenciados pelo smart tier, pois eles podem entrar em conflito.

Conclusão

Isso não é revolucionário, mas resolve uma dor de cabeça operacional real. Se você gerencia contas de blob storage em crescimento e está cansado de manter políticas de ciclo de vida, habilite o smart tier e deixe o Azure cuidar disso. Está disponível hoje em quase todas as regiões zonais da nuvem pública.

Onde hospedar seus agentes de IA no Azure? Um guia prático de decisão

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

Se você está construindo agentes de IA com .NET agora, provavelmente notou algo: existem muitas formas de hospedá-los no Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — e todos parecem razoáveis até você precisar escolher um. A Microsoft acabou de publicar um guia completo sobre hospedagem de agentes IA no Azure que esclarece isso, e eu quero detalhar tudo pela perspectiva prática de um desenvolvedor .NET.

As seis opções de relance

Aqui está como eu resumiria o cenário:

Opção	Melhor para	Você gerencia
Container Apps	Controle total de containers sem complexidade K8s	Observabilidade, estado, ciclo de vida
AKS	Compliance empresarial, multi-cluster, rede customizada	Tudo (esse é o ponto)
Azure Functions	Tarefas de agentes curtas e orientadas a eventos	Quase nada — serverless real
App Service	Agentes HTTP simples, tráfego previsível	Deploy, config de scaling
Foundry Agents	Agentes sem código via portal/SDK	Quase nada
Foundry Hosted Agents	Agentes com framework customizado e infra gerenciada	Apenas seu código de agente

As quatro primeiras são computação de propósito geral — você pode rodar agentes nelas, mas não foram projetadas para isso. As duas últimas são nativas de agentes: entendem conversas, chamadas de ferramentas e ciclos de vida de agentes como conceitos de primeira classe.

Foundry Hosted Agents — o ponto ideal para desenvolvedores .NET de agentes

Isso foi o que chamou minha atenção. Foundry Hosted Agents ficam bem no meio: você tem a flexibilidade de rodar seu próprio código (Semantic Kernel, Agent Framework, LangGraph — o que for) mas a plataforma cuida da infraestrutura, observabilidade e gerenciamento de conversas.

A peça-chave é o Hosting Adapter — uma camada de abstração fina que conecta seu framework de agentes à plataforma Foundry. Para o Microsoft Agent Framework, fica assim:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Essa é toda a sua história de hosting. O adapter cuida da tradução de protocolos, streaming via server-sent events, histórico de conversa e rastreamento OpenTelemetry — tudo automaticamente. Sem middleware customizado, sem encanamento manual.

Deploy é genuinamente simples

Já fiz deploy de agentes no Container Apps antes e funciona, mas você acaba escrevendo muito código de cola para gerenciamento de estado e observabilidade. Com Hosted Agents e azd, o deploy é:

# Instalar a extensão de agente IA
azd ext install azure.ai.agents

# Inicializar a partir de um template
azd ai agent init

# Construir, enviar, fazer deploy — pronto
azd up

Esse único azd up constrói seu container, envia para o ACR, provisiona o projeto Foundry, faz deploy dos endpoints de modelo e inicia seu agente. Cinco etapas condensadas em um único comando.

Gerenciamento de conversas integrado

Essa é a parte que economiza mais tempo em produção. Em vez de construir seu próprio store de estado de conversa, Hosted Agents lidam com isso nativamente:

# Criar uma conversa persistente
conversation = openai_client.conversations.create()

# Primeira rodada
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Segunda rodada — contexto é preservado
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Sem Redis. Sem store de sessões Cosmos DB. Sem middleware customizado para serialização de mensagens. A plataforma simplesmente cuida disso.

Meu framework de decisão

Depois de passar pelas seis opções, aqui está meu modelo mental rápido:

Precisa de zero infraestrutura? → Foundry Agents (portal/SDK, sem containers)
Tem código de agente customizado mas quer hosting gerenciado? → Foundry Hosted Agents
Precisa de tarefas de agentes curtas orientadas a eventos? → Azure Functions
Precisa de máximo controle de containers sem K8s? → Container Apps
Precisa de compliance rigorosa e multi-cluster? → AKS
Tem um agente HTTP simples com tráfego previsível? → App Service

Para a maioria dos desenvolvedores .NET construindo com Semantic Kernel ou Microsoft Agent Framework, Hosted Agents é provavelmente o ponto de partida certo. Você obtém scale-to-zero, OpenTelemetry integrado, gerenciamento de conversas e flexibilidade de framework — sem gerenciar Kubernetes ou montar sua própria stack de observabilidade.

Para finalizar

O cenário de hospedagem de agentes no Azure está amadurecendo rápido. Se você está começando um novo projeto de agente IA hoje, eu consideraria seriamente Foundry Hosted Agents antes de recorrer a Container Apps ou AKS por hábito. A infraestrutura gerenciada economiza tempo real, e o padrão hosting adapter permite manter sua escolha de framework.

Confira o guia completo da Microsoft e o repo Foundry Samples para exemplos funcionais.

As Agent Skills no .NET ficaram realmente flexíveis

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

Se você tem construído agentes com o Microsoft Agent Framework, já conhece o processo: define skills, conecta a um provider e deixa o agente decidir qual invocar. O que há de novo é como você cria essas skills — e o salto em flexibilidade é significativo.

A última atualização introduz três padrões de autoria para agent skills: baseadas em arquivos, baseadas em classes e definidas em código inline. As três se conectam a um único AgentSkillsProviderBuilder, o que significa que você pode misturar e combinar sem lógica de roteamento nem código especial. Vou te mostrar cada uma e quando usar.

Skills baseadas em arquivos: o ponto de partida

Skills baseadas em arquivos são exatamente o que parecem — um diretório no disco com um arquivo SKILL.md, scripts opcionais e documentos de referência. A forma mais direta de dar novas capacidades ao seu agente:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

O frontmatter do SKILL.md declara o nome e descrição, e a seção de instruções diz ao agente como usar os scripts e referências:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Depois você conecta com SubprocessScriptRunner.RunAsync para execução de scripts:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

O agente descobre a skill automaticamente e invoca o script de provisioning quando precisa verificar o status das contas. Limpo e simples.

Skills baseadas em classes: distribuir via NuGet

Aqui é onde fica interessante para times. Skills baseadas em classes derivam de AgentClassSkill<T> e usam atributos como [AgentSkillResource] e [AgentSkillScript] para que o framework descubra tudo por reflexão:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

O legal é que um time pode empacotar isso como pacote NuGet. Você adiciona ao projeto, coloca no builder e funciona junto com suas skills de arquivo sem coordenação:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Ambas as skills aparecem no system prompt do agente. O agente decide qual usar baseado na conversa — sem código de roteamento.

Skills inline: a ponte rápida

Sabe aquele momento quando outro time está construindo exatamente a skill que você precisa, mas só vai ficar pronta no próximo sprint? AgentInlineSkill é sua ponte:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Adicione ao builder assim como as outras:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Quando o pacote NuGet finalmente sair, você troca a skill inline pela versão baseada em classe. O agente não percebe a diferença.

Mas skills inline não são só para pontes. Também são a escolha certa quando você precisa gerar skills dinamicamente em runtime — pense em uma skill por unidade de negócio carregada de configuração — ou quando um script precisa capturar estado local que não pertence a um contêiner DI.

Aprovação de scripts: humano no loop

Para nós desenvolvedores .NET construindo agentes de produção, essa é a parte que realmente desbloqueia conversas de deploy. Alguns scripts têm consequências reais — inscrever alguém em benefícios, consultar infraestrutura de produção. Ative UseScriptApproval e o agente pausa antes de executar qualquer script:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Quando o agente quer executar um script, retorna um pedido de aprovação. Seu app coleta a decisão — aprovar ou rejeitar — e o agente continua. Em ambientes regulados, essa é a diferença entre “podemos fazer deploy disso” e “o jurídico disse não.”

Por que essa combinação importa

O verdadeiro poder não está em nenhum padrão individual — está na composição. Você pode:

Começar pequeno com uma skill de arquivo, iterar nas instruções e publicar sem escrever C#
Distribuir skills reutilizáveis como pacotes NuGet que outros times adicionam com uma linha
Cobrir lacunas com skills inline quando precisa de algo agora
Filtrar diretórios compartilhados com predicados para que seu agente só carregue o que deve
Adicionar supervisão humana para scripts que tocam sistemas de produção

Tudo isso se compõe via AgentSkillsProviderBuilder. Sem roteamento especial, sem lógica condicional, sem verificações de tipo de skill.

Para encerrar

As agent skills no .NET agora têm um modelo de autoria genuinamente flexível. Seja você um desenvolvedor solo prototipando com skills de arquivo ou um time enterprise distribuindo capacidades empacotadas via NuGet, os padrões se encaixam. E o mecanismo de aprovação de scripts o torna pronto para produção em ambientes onde você precisa daquele checkpoint humano.

Confira o anúncio original, a documentação de Agent Skills no Microsoft Learn e os exemplos .NET no GitHub para começar.

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.

A Engenharia de Plataformas Agêntica Está se Tornando Real — Git-APE Mostra Como

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

Engenharia de plataformas tem sido um daqueles termos que soam ótimos em conferências, mas que normalmente significam “construímos um portal interno e um wrapper de Terraform.” A verdadeira promessa — infraestrutura self-service que seja realmente segura, governada e rápida — sempre esteve a alguns passos de distância.

O time Azure acaba de publicar a Parte 2 da série sobre engenharia de plataformas agêntica, e esta é toda sobre a implementação prática. Eles chamam de Git-APE (sim, a sigla é intencional), e é um projeto open source que usa agentes do GitHub Copilot mais servidores Azure MCP para transformar solicitações em linguagem natural em infraestrutura validada e implantada.

O que o Git-APE realmente faz

A ideia central: em vez de desenvolvedores aprenderem módulos Terraform, navegarem por UIs de portais ou abrirem tickets para o time de plataforma, eles conversam com um agente Copilot. O agente interpreta a intenção, gera Infrastructure-as-Code, valida contra políticas e implanta — tudo dentro do VS Code.

Aqui está a configuração:

git clone https://github.com/Azure/git-ape
cd git-ape

Abra o workspace no VS Code, e os arquivos de configuração do agente são descobertos automaticamente pelo GitHub Copilot. Você interage diretamente com o agente:

@git-ape deploy a function app with storage in West Europe

O agente usa o Azure MCP Server por baixo dos panos para interagir com os serviços Azure. A configuração MCP nas opções do VS Code habilita capacidades específicas:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Por que isso importa

Para nós que construímos no Azure, isso muda a conversa de engenharia de plataformas de “como construímos um portal” para “como descrevemos nossas guardrails como APIs.” Quando a interface da sua plataforma é um agente de IA, a qualidade das suas restrições e políticas se torna o produto.

O blog da Parte 1 apresentou a teoria: APIs bem descritas, schemas de controle e guardrails explícitas tornam as plataformas agent-ready. A Parte 2 prova que funciona entregando ferramentas reais. O agente não gera recursos cegamente — valida contra melhores práticas, respeita convenções de nomenclatura e aplica as políticas da sua organização.

A limpeza é igualmente simples:

@git-ape destroy my-resource-group

Minha opinião

Vou ser honesto — aqui é mais sobre o padrão do que sobre a ferramenta específica. O Git-APE em si é uma demo/arquitetura de referência. Mas a ideia subjacente — agentes como a interface da sua plataforma, MCP como protocolo, GitHub Copilot como host — é para onde a experiência do desenvolvedor enterprise está caminhando.

Se você é um time de plataforma procurando como tornar seu ferramental interno amigável para agentes, não há melhor ponto de partida. E se você é um desenvolvedor .NET se perguntando como isso se conecta ao seu mundo: o Azure MCP Server e os agentes do GitHub Copilot funcionam com qualquer workload Azure. Sua API ASP.NET Core, seu stack .NET Aspire, seus microsserviços em containers — tudo pode ser alvo de um fluxo de deploy agêntico.

Concluindo

Git-APE é um olhar inicial mas concreto sobre engenharia de plataformas agêntica na prática. Clone o repo, experimente a demo e comece a pensar em como as APIs e políticas da sua plataforma precisariam ser para que um agente as use com segurança.

Leia o post completo para o walkthrough e vídeos de demonstração.

Aquela Configuração de Janelas Flutuantes do Visual Studio Que Você Não Conhecia (Mas Deveria)

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

Se você usa múltiplos monitores com o Visual Studio (e honestamente, quem não usa hoje em dia?), provavelmente já passou pela frustração: janelas flutuantes de ferramentas desaparecem quando você minimiza a IDE principal, elas sempre ficam em cima de tudo, e não aparecem como botões separados na barra de tarefas. Funciona para alguns fluxos de trabalho, mas para configurações com múltiplos monitores é frustrante.

Mads Kristensen da equipe do Visual Studio compartilhou uma configuração pouco conhecida que muda completamente como as janelas flutuantes se comportam. Um dropdown. Só isso.

A configuração

Tools > Options > Environment > Windows > Floating Windows

O dropdown “These floating windows are owned by the main window” tem três opções:

None — independência total. Cada janela flutuante tem sua própria entrada na barra de tarefas e se comporta como uma janela normal do Windows.
Tool Windows (padrão) — documentos flutuam livremente, janelas de ferramentas ficam vinculadas à IDE.
Documents and Tool Windows — comportamento clássico do Visual Studio, tudo vinculado à janela principal.

Por que “None” é a melhor escolha para configurações com múltiplos monitores

Configure para None e de repente todas as suas janelas flutuantes de ferramentas e documentos se comportam como aplicações reais do Windows. Elas aparecem na barra de tarefas, ficam visíveis quando você minimiza a janela principal do Visual Studio, e param de se forçar para frente de tudo.

Combine isso com PowerToys FancyZones e é uma mudança total. Crie layouts personalizados nos seus monitores, encaixe seu Gerenciador de Soluções em uma zona, depurador em outra, e arquivos de código onde quiser. Tudo fica no lugar, tudo é acessível de forma independente, e seu espaço de trabalho parece organizado em vez de caótico.

Recomendações rápidas

Usuários avançados com múltiplos monitores: Configure para None, combine com FancyZones
Flutuadores ocasionais: Tool Windows (padrão) é um bom meio-termo
Fluxo de trabalho tradicional: Documents and Tool Windows mantém tudo clássico

Dica pro: Ctrl + duplo clique na barra de título de qualquer janela de ferramentas para flutuá-la ou ancorar instantaneamente. Não precisa reiniciar após mudar a configuração.

Conclusão

É uma daquelas configurações do tipo “não acredito que eu não sabia disso”. Se as janelas flutuantes do Visual Studio já te irritaram, vá mudar isso agora mesmo.

Leia o post completo para detalhes e capturas de tela.

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.

Construindo UIs Multi-Agente em Tempo Real Que Não Parecem uma Caixa Preta

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

A questão com sistemas multi-agente é a seguinte: eles ficam incríveis nas demos. Três agentes passando trabalho entre si, resolvendo problemas, tomando decisões. Aí você tenta colocar na frente de usuários reais e… silêncio. Um indicador girando. Nenhuma ideia de qual agente está fazendo o quê ou por que o sistema pausou. Isso não é um produto — é um problema de confiança.

O time do Microsoft Agent Framework acabou de publicar um tutorial fantástico sobre como combinar fluxos MAF com AG-UI, um protocolo aberto para transmitir eventos de execução de agentes para um frontend via Server-Sent Events. E sinceramente? Essa é a ponte que estava faltando.

Por que isso importa para desenvolvedores .NET

Se você está construindo apps com IA, provavelmente já bateu nesse muro. Sua orquestração backend funciona perfeitamente — agentes passam tarefas entre si, ferramentas disparam, decisões são tomadas. Mas o frontend não faz ideia do que está acontecendo nos bastidores. AG-UI resolve isso definindo um protocolo padrão para transmitir eventos de agentes (pense em RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) diretamente para sua camada de UI via SSE.

A demo que construíram é um fluxo de suporte ao cliente com três agentes: um agente de triagem que roteia solicitações, um agente de reembolso que cuida de questões financeiras, e um agente de pedidos que gerencia substituições. Cada agente tem suas próprias ferramentas, e a topologia de handoff é definida explicitamente — nada de “descubra a partir do prompt”.

A topologia de handoff é a verdadeira estrela

O que me chamou a atenção é como o HandoffBuilder permite declarar um grafo dirigido de roteamento entre agentes:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Cada add_handoff cria uma aresta dirigida com uma descrição em linguagem natural. O framework gera ferramentas de handoff para cada agente baseado nessa topologia. Então as decisões de roteamento são fundamentadas na sua estrutura de orquestração, não apenas no que o LLM resolve fazer. Isso é enorme para confiabilidade em produção.

Human-in-the-loop que realmente funciona

A demo mostra dois padrões de interrupção que qualquer app de agentes do mundo real precisa:

Interrupções de aprovação de ferramentas — quando um agente chama uma ferramenta marcada com approval_mode="always_require", o fluxo pausa e emite um evento. O frontend renderiza um modal de aprovação com o nome da ferramenta e seus argumentos. Sem loops de retry queimando tokens — apenas um fluxo limpo de pausa-aprovação-retomada.

Interrupções de solicitação de informação — quando um agente precisa de mais contexto do usuário (como um ID de pedido), ele pausa e pergunta. O frontend mostra a pergunta, o usuário responde, e a execução retoma exatamente de onde parou.

Ambos os padrões são transmitidos como eventos AG-UI padrão, então seu frontend não precisa de lógica personalizada por agente — simplesmente renderiza qualquer evento que chegue pela conexão SSE.

Conectar tudo é surpreendentemente simples

A integração entre MAF e AG-UI é uma única chamada de função:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

O workflow_factory cria um fluxo novo por thread, então cada conversa tem estado isolado. O endpoint cuida de toda a tubulação SSE automaticamente. Se você já usa FastAPI (ou pode adicioná-lo como uma camada leve), isso tem praticamente zero fricção.

Minha opinião

Para nós desenvolvedores .NET, a pergunta imediata é: “Posso fazer isso em C#?” O Agent Framework está disponível para .NET e Python, e o protocolo AG-UI é agnóstico de linguagem (é apenas SSE). Então embora essa demo específica use Python e FastAPI, o padrão se traduz diretamente. Você poderia montar uma API mínima ASP.NET Core com endpoints SSE seguindo o mesmo schema de eventos AG-UI.

A conclusão mais importante é que UIs multi-agente estão se tornando uma preocupação de primeira classe, não algo deixado para depois. Se você está construindo qualquer coisa onde agentes interagem com humanos — suporte ao cliente, fluxos de aprovação, processamento de documentos — essa combinação de orquestração MAF e transparência AG-UI é o padrão a seguir.

Concluindo

AG-UI + Microsoft Agent Framework te dá o melhor dos dois mundos: orquestração multi-agente robusta no backend e visibilidade em tempo real no frontend. Sem mais interações de agentes como caixas pretas.

Confira o tutorial completo e o repositório do protocolo AG-UI para se aprofundar.

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.

Microsoft Foundry Março 2026 — GPT-5.4, Agent Service GA e a Atualização do SDK Que Muda Tudo

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

Os posts mensais de “Novidades no Microsoft Foundry” costumam ser uma mistura de melhorias incrementais e alguma funcionalidade destaque ocasional. A edição de março de 2026? É basicamente tudo destaque. Foundry Agent Service chega ao GA, GPT-5.4 é lançado para produção, o SDK recebe uma grande versão estável, e Fireworks AI traz inferência de modelos abertos para o Azure. Vamos detalhar o que importa para desenvolvedores .NET.

Foundry Agent Service está pronto para produção

Essa é a grande novidade. O runtime de agentes de nova geração está em disponibilidade geral — construído sobre a API Responses da OpenAI, compatível em protocolo com agentes OpenAI, e aberto a modelos de múltiplos provedores. Se você está construindo com a API Responses hoje, migrar para o Foundry adiciona segurança empresarial, rede privada, RBAC do Entra, rastreamento completo e avaliação sobre sua lógica de agentes existente.

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

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

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.",
 ),
)

Adições principais: rede privada de ponta a ponta, expansão de autenticação MCP (incluindo passthrough OAuth), preview do Voice Live para agentes de voz para voz, e agentes hospedados em 6 novas regiões.

GPT-5.4 — confiabilidade acima de inteligência pura

GPT-5.4 não é sobre ser mais inteligente. É sobre ser mais confiável. Raciocínio mais forte em interações longas, melhor aderência a instruções, menos falhas no meio de workflows, e capacidades integradas de uso de computador. Para agentes em produção, essa confiabilidade importa muito mais do que pontuações em benchmarks.

Modelo	Preço (por M tokens)	Ideal Para
GPT-5.4 (≤272K)	$2.50 / $15 saída	Agentes em produção, código, fluxos de documentos
GPT-5.4 Pro	$30 / $180 saída	Análise profunda, raciocínio científico
GPT-5.4 Mini	Econômico	Classificação, extração, chamadas leves de ferramentas

A jogada inteligente é uma estratégia de roteamento: GPT-5.4 Mini lida com o trabalho de alto volume e baixa latência enquanto GPT-5.4 cuida das solicitações com raciocínio pesado.

O SDK finalmente está estável

O SDK azure-ai-projects lançou versões estáveis em todas as linguagens — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0, e .NET 2.0.0 (1º de abril). A dependência do azure-ai-agents sumiu — tudo vive sob AIProjectClient. Instale com pip install azure-ai-projects e o pacote inclui openai e azure-identity como dependências diretas.

Para desenvolvedores .NET, isso significa um único pacote NuGet para toda a superfície do Foundry. Chega de malabarismo com SDKs de agentes separados.

Fireworks AI traz modelos abertos para o Azure

Talvez a adição mais interessante arquitetonicamente: Fireworks AI processando mais de 13 trilhões de tokens por dia a ~180K requisições/segundo, agora disponível através do Foundry. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5, e MiniMax M2.5 no lançamento.

A verdadeira história é o bring-your-own-weights — faça upload de pesos quantizados ou fine-tunados de qualquer lugar sem mudar a stack de serving. Deploy via serverless pay-per-token ou throughput provisionado.

Outros destaques

Phi-4 Reasoning Vision 15B — raciocínio multimodal para gráficos, diagramas e layouts de documentos
Evaluations GA — avaliadores prontos para uso com monitoramento contínuo de produção integrado ao Azure Monitor
Priority Processing (Preview) — faixa de computação dedicada para cargas de trabalho sensíveis à latência
Voice Live — runtime de voz para voz que se conecta diretamente aos agentes do Foundry
Tracing GA — inspeção de rastreamento de agentes de ponta a ponta com ordenação e filtragem
Depreciação do PromptFlow — migração para Microsoft Framework Workflows até janeiro de 2027

Conclusão

Março de 2026 é um ponto de virada para o Foundry. Agent Service GA, SDKs estáveis em todas as linguagens, GPT-5.4 para agentes de produção confiáveis, e inferência de modelos abertos via Fireworks AI — a plataforma está pronta para cargas de trabalho sérias.

Leia o resumo completo e crie seu primeiro agente para começar.

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.

SQL MCP Server — A forma certa de dar acesso a bancos de dados para agentes de IA

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

Vamos ser honestos: a maioria dos servidores MCP de banco de dados disponíveis hoje são assustadores. Eles pegam uma consulta em linguagem natural, geram SQL na hora e executam contra seus dados de produção. O que poderia dar errado? (Tudo. Tudo poderia dar errado.)

O time do Azure SQL acabou de apresentar o SQL MCP Server, e ele adota uma abordagem fundamentalmente diferente. Construído como uma funcionalidade do Data API builder (DAB) 2.0, dá aos agentes de IA acesso estruturado e determinístico a operações de banco de dados — sem NL2SQL, sem expor seu esquema, e com RBAC completo em cada etapa.

Por que não NL2SQL?

Essa é a decisão de design mais interessante. Modelos não são determinísticos, e consultas complexas são as mais propensas a produzir erros sutis. As consultas exatas que os usuários esperam que a IA gere são também as que precisam de mais escrutínio quando produzidas de forma não determinística.

Em vez disso, o SQL MCP Server usa uma abordagem NL2DAB. O agente trabalha com a camada de abstração de entidades do Data API builder e seu construtor de consultas integrado para produzir T-SQL preciso e bem formado de maneira determinística. Mesmo resultado para o usuário, mas sem o risco de JOINs alucinados ou exposição acidental de dados.

Sete ferramentas, não setecentas

O SQL MCP Server expõe exatamente sete ferramentas DML, independentemente do tamanho do banco de dados:

describe_entities — descobrir entidades e operações disponíveis
create_record — inserir linhas
read_records — consultar tabelas e views
update_record — modificar linhas
delete_record — remover linhas
execute_entity — executar stored procedures
aggregate_records — consultas de agregação

Isso é inteligente porque janelas de contexto são o espaço de pensamento do agente. Inundá-las com centenas de definições de ferramentas deixa menos espaço para raciocínio. Sete ferramentas fixas mantêm o agente focado em pensar em vez de navegar.

Cada ferramenta pode ser habilitada ou desabilitada individualmente:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Começando em três comandos

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Isso é um SQL MCP Server rodando e expondo sua tabela Customers. A camada de abstração de entidades significa que você pode criar aliases para nomes e colunas, limitar campos por papel, e controlar exatamente o que os agentes veem — sem expor detalhes internos do esquema.

A história de segurança é sólida

É aqui que a maturidade do Data API builder compensa:

RBAC em cada camada — cada entidade define quais papéis podem ler, criar, atualizar ou deletar, e quais campos são visíveis
Integração com Azure Key Vault — strings de conexão e segredos gerenciados com segurança
Microsoft Entra + OAuth personalizado — autenticação de nível de produção
Content Security Policy — agentes interagem através de um contrato controlado, não SQL cru

A abstração de esquema é particularmente importante. Seus nomes internos de tabelas e colunas nunca são expostos ao agente. Você define entidades, aliases e descrições que fazem sentido para a interação com IA — não seu diagrama ERD do banco de dados.

Multi-banco e multi-protocolo

O SQL MCP Server suporta Microsoft SQL, PostgreSQL, Azure Cosmos DB e MySQL. E como é uma funcionalidade do DAB, você obtém endpoints REST, GraphQL e MCP simultaneamente da mesma configuração. Mesmas definições de entidades, mesmas regras RBAC, mesma segurança — nos três protocolos.

A auto-configuração no DAB 2.0 pode até inspecionar seu banco de dados e construir a configuração dinamicamente, se você estiver confortável com menos abstração para prototipagem rápida.

Minha opinião

É assim que o acesso empresarial a bancos de dados para agentes de IA deveria funcionar. Não “ei LLM, escreve SQL pra mim e YOLO contra produção.” Em vez disso: uma camada de entidades bem definida, geração determinística de consultas, RBAC em cada etapa, cache, monitoramento e telemetria. É chato da melhor maneira possível.

Para desenvolvedores .NET, a história de integração é limpa — DAB é uma ferramenta .NET, o MCP Server roda como contêiner, e funciona com Azure SQL, que a maioria de nós já está usando. Se você está construindo agentes de IA que precisam de acesso a dados, comece aqui.

Finalizando

SQL MCP Server é gratuito, open-source e roda em qualquer lugar. É a abordagem prescritiva da Microsoft para dar aos agentes de IA acesso seguro a bancos de dados. Confira o post completo e a documentação para começar.

VS Code 1.116 — App de Agentes Ganha Navegação por Teclado e Autocompletação de Contexto de Arquivos

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

VS Code 1.116 é a versão de abril de 2026, e embora seja mais leve que algumas atualizações recentes, as mudanças são focadas e significativas — especialmente se você está usando a app de Agentes diariamente.

Aqui está o que chegou, baseado nas notas de versão oficiais.

Melhorias na app de Agentes

A app de Agentes continua amadurecendo com polimento de usabilidade que faz uma diferença real nos fluxos de trabalho diários:

Atalhos de teclado dedicados — agora você pode focar a visualização de Mudanças, a árvore de arquivos dentro de Mudanças e a visualização de Personalizações do Chat com comandos e atalhos de teclado dedicados. Se você estava clicando pela app de Agentes para navegar, isso traz fluxos de trabalho totalmente controlados por teclado.

Diálogo de ajuda de acessibilidade — pressionar Alt+F1 na caixa de entrada do chat agora abre um diálogo de ajuda de acessibilidade mostrando comandos e atalhos disponíveis. Usuários de leitores de tela também podem controlar a verbosidade dos anúncios. Boa acessibilidade beneficia a todos.

Autocompletação de contexto de arquivos — digite # no chat da app de Agentes para ativar autocompletação de contexto de arquivos no seu workspace atual. Esta é uma daquelas pequenas melhorias de qualidade de vida que aceleram cada interação — chega de digitar caminhos completos de arquivos ao referenciar código.

Resolução de links CSS `@import`

Uma boa para desenvolvedores frontend: VS Code agora resolve referências CSS @import que usam caminhos de node_modules. Você pode fazer Ctrl+clique através de imports como @import "some-module/style.css" ao usar bundlers. Pequeno, mas elimina um ponto de atrito nos fluxos de trabalho CSS.

Conclusão

VS Code 1.116 é sobre refinamento — tornar a app de Agentes mais navegável, mais acessível e mais amigável ao teclado. Se você passa tempo significativo na app de Agentes (e suspeito que muitos de nós passamos), essas mudanças se acumulam.

Confira as notas de versão completas para a lista completa.

VS Code 1.115 — Notificações de Terminal em Segundo Plano, Modo Agente SSH e Mais

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 acabou de ser lançado, e embora seja uma versão mais leve em termos de funcionalidades principais, as melhorias relacionadas a agentes são genuinamente úteis se você trabalha com assistentes de código com IA diariamente.

Deixa eu destacar o que realmente vale a pena saber.

Terminais em segundo plano se comunicam com agentes

Essa é a funcionalidade destaque. Terminais em segundo plano agora notificam automaticamente os agentes quando comandos são concluídos, incluindo o código de saída e a saída do terminal. Prompts de entrada em terminais em segundo plano também são detectados e exibidos ao usuário.

Por que isso importa? Se você usou o modo agente do Copilot para executar comandos de build ou suítes de testes em segundo plano, você conhece a dor do “será que já terminou?” — terminais em segundo plano eram essencialmente disparar-e-esquecer. Agora o agente é notificado quando seu dotnet build ou dotnet test termina, vê a saída e pode reagir de acordo. É uma mudança pequena que torna os fluxos de trabalho orientados por agentes significativamente mais confiáveis.

Há também uma nova ferramenta send_to_terminal que permite aos agentes enviar comandos para terminais em segundo plano com confirmação do usuário, corrigindo o problema onde run_in_terminal com um timeout movia terminais para segundo plano e os deixava somente leitura.

Hospedagem remota de agentes via SSH

VS Code agora suporta conexão a máquinas remotas via SSH, instalando automaticamente o CLI e iniciando-o em modo host de agentes. Isso significa que suas sessões de agentes de IA podem mirar ambientes remotos diretamente — útil para desenvolvedores .NET que compilam e testam em servidores Linux ou VMs na nuvem.

Rastreamento de edições em sessões de agentes

Edições de arquivos feitas durante sessões de agentes agora são rastreadas e restauradas, com diffs, desfazer/refazer e restauração de estado. Se um agente faz alterações no seu código e algo dá errado, você pode ver exatamente o que mudou e reverter. Tranquilidade para deixar agentes modificarem sua codebase.

Reconhecimento de abas do navegador e outras melhorias

Mais algumas adições de qualidade de vida:

Rastreamento de abas do navegador — o chat agora pode rastrear e linkar abas do navegador abertas durante uma sessão, para que agentes possam referenciar páginas web que você está visualizando
Colagem de arquivos no terminal — cole arquivos (incluindo imagens) no terminal com Ctrl+V, arrastar e soltar, ou clique direito
Cobertura de testes no minimap — indicadores de cobertura de testes agora aparecem no minimap para uma visão visual rápida
Pinch-to-zoom no Mac — o navegador integrado suporta gestos de pinch-to-zoom
Direitos do Copilot em Sessões — a barra de status mostra informações de uso na visualização de Sessões
Favicon em Ir para Arquivo — páginas web abertas mostram favicons na lista de seleção rápida

Conclusão

VS Code 1.115 é uma versão incremental, mas as melhorias de agentes — notificações de terminal em segundo plano, hospedagem de agentes SSH e rastreamento de edições — somam-se a uma experiência notavelmente mais fluida para desenvolvimento assistido por IA. Se você está usando o modo agente do Copilot para projetos .NET, esses são o tipo de melhorias de qualidade de vida que reduzem o atrito no dia a dia.

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

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.

Azure DevOps finalmente corrige o editor Markdown que todo mundo reclamava

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

Se você usa Azure Boards, provavelmente já passou por isso: está lendo a descrição de um work item, talvez revisando critérios de aceitação, e acidentalmente dá um duplo clique. Boom — está em modo de edição. Não queria editar nada. Estava apenas lendo.

Dan Hellem anunciou a correção, e é uma daquelas mudanças que parecem pequenas mas realmente removem fricção do seu fluxo de trabalho diário.

O que mudou

O editor Markdown para campos de texto de work items agora abre em modo de visualização por padrão. Você pode ler e interagir com o conteúdo — seguir links, revisar formatação — sem se preocupar em entrar acidentalmente no modo de edição.

Quando realmente quer editar, clica no ícone de edição no topo do campo. Quando termina, sai explicitamente para o modo de visualização. Simples, intencional, previsível.

Por que isso importa mais do que parece

O thread de feedback da comunidade era longo. O comportamento de duplo clique para editar foi introduzido com o editor Markdown em julho de 2025, e as reclamações começaram quase imediatamente.

Para times que fazem planejamento de sprint, refinamento de backlog ou revisão de código com Azure Boards, esse tipo de micro-fricção se acumula.

Status da implantação

Já está sendo implementado para um subconjunto de clientes e se expandirá para todos nas próximas duas a três semanas.

Conclusão

Nem toda melhoria precisa ser uma funcionalidade de destaque. Às vezes a melhor atualização é simplesmente remover algo irritante. Esta é uma dessas — uma pequena correção de UX que torna o Azure Boards menos hostil para pessoas que só querem ler seus work items em paz.

Bookmark Studio traz navegação por slots e compartilhamento para marcadores do Visual Studio

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

Marcadores no Visual Studio sempre foram… ok. Você coloca um, navega para o próximo, esquece qual é qual. Funcionam, mas nunca foram algo que você chamaria de poderoso.

Mads Kristensen acabou de lançar o Bookmark Studio, uma extensão experimental que preenche exatamente as lacunas que você provavelmente encontrou.

Navegação por slots

Marcadores podem ser atribuídos a slots de 1 a 9 e acessados diretamente com Alt+Shift+1 a Alt+Shift+9. Novos marcadores recebem automaticamente o próximo slot disponível.

O Gerenciador de Marcadores

Uma nova janela exibe todos os marcadores com filtragem por nome, arquivo, localização, cor ou slot.

Organização com labels, cores e pastas

Marcadores podem ter labels, cores e serem agrupados em pastas. Metadata armazenada por solução.

Exportar e compartilhar

Bookmark Studio permite exportar marcadores como texto, Markdown ou CSV.

Marcadores que acompanham o código

Bookmark Studio rastreia marcadores relativos ao texto ancorado, então não se deslocam para linhas erradas.

Conclusão

Bookmark Studio não reinventa nada. Pega uma funcionalidade que era “suficiente” há anos e a torna genuinamente útil. Baixe no Visual Studio Marketplace.

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.

SQL MCP Server, Copilot no SSMS e um Database Hub com Agentes de IA: O que realmente importa da SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

A Microsoft acabou de abrir a SQLCon 2026 junto com a FabCon em Atlanta, e tem muita coisa para desempacotar. O anúncio original cobre tudo, desde planos de economia até funcionalidades de conformidade enterprise. Eu vou pular os slides de preços enterprise e focar nas partes que importam se você é um desenvolvedor construindo coisas com Azure SQL e IA.

SQL MCP Server está em public preview

Essa é a manchete principal pra mim. O Azure SQL Database Hyperscale agora tem um SQL MCP Server em public preview que permite conectar seus dados SQL de forma segura a agentes de IA e Copilots usando o Model Context Protocol.

Se você tem acompanhado a onda do MCP — e honestamente, é difícil não perceber agora — isso é uma grande novidade. Em vez de construir pipelines de dados customizados para alimentar seus agentes de IA com contexto do seu banco de dados, você ganha um protocolo padronizado para expor dados SQL diretamente. Seus agentes podem consultar, raciocinar e agir sobre informações do banco de dados em tempo real.

Para quem está construindo agentes de IA com Semantic Kernel ou o Microsoft Agent Framework, isso abre um caminho de integração limpo. Seu agente precisa verificar o estoque? Buscar um registro de cliente? Validar um pedido? O MCP dá a ele uma forma estruturada de fazer isso sem você escrever código de busca de dados sob medida para cada cenário.

GitHub Copilot no SSMS 22 agora é GA

Se você passa algum tempo no SQL Server Management Studio — e sejamos honestos, a maioria de nós ainda passa — o GitHub Copilot agora está disponível de forma geral no SSMS 22. A mesma experiência Copilot que você já usa no VS Code e Visual Studio, mas para T-SQL.

O valor prático aqui é direto: assistência por chat para escrever queries, refatorar stored procedures, resolver problemas de performance e lidar com tarefas administrativas. Nada revolucionário no conceito, mas ter isso dentro do SSMS significa que você não precisa trocar de contexto para outro editor só para ter ajuda de IA no seu trabalho com banco de dados.

Índices vetoriais receberam um upgrade sério

O Azure SQL Database agora tem índices vetoriais mais rápidos e mais robustos com suporte completo para insert, update e delete. Isso significa que seus dados vetoriais ficam atualizados em tempo real — sem necessidade de reindexação em lote.

Aqui está o que há de novo:

Quantização para tamanhos de índice menores sem perder muita precisão
Filtragem iterativa para resultados mais precisos
Integração mais próxima com o otimizador de queries para performance previsível

Se você está fazendo Retrieval-Augmented Generation (RAG) com Azure SQL como vector store, essas melhorias são diretamente úteis. Você pode manter seus vetores junto com seus dados relacionais no mesmo banco de dados, o que simplifica significativamente sua arquitetura comparado a rodar um banco de dados vetorial separado.

As mesmas melhorias vetoriais também estão disponíveis no SQL Database no Fabric, já que ambos rodam no mesmo motor SQL por baixo dos panos.

Database Hub no Fabric: gestão agêntica

Esse ponto é mais voltado para o futuro, mas é interessante. A Microsoft anunciou o Database Hub no Microsoft Fabric (acesso antecipado), que te dá uma visão unificada sobre Azure SQL, Cosmos DB, PostgreSQL, MySQL e SQL Server via Arc.

O ângulo interessante não é só a visão unificada — é a abordagem agêntica de gestão. Agentes de IA monitoram continuamente seu parque de bancos de dados, mostram o que mudou, explicam por que isso importa e sugerem o que fazer em seguida. É um modelo human-in-the-loop onde o agente faz o trabalho pesado e você toma as decisões.

Para equipes gerenciando mais do que um punhado de bancos de dados, isso poderia realmente reduzir o ruído operacional. Em vez de pular entre portais e verificar métricas manualmente, o agente traz o sinal até você.

O que isso significa para desenvolvedores .NET

O fio que conecta todos esses anúncios é claro: a Microsoft está incorporando agentes de IA em cada camada da stack de banco de dados. Não como um truque, mas como uma camada prática de ferramentas.

Se você está construindo apps .NET com Azure SQL, aqui está o que eu faria de fato:

Experimente o SQL MCP Server se você está construindo agentes de IA. É a forma mais limpa de dar aos seus agentes acesso ao banco de dados sem encanamento customizado.
Ative o Copilot no SSMS se você ainda não fez — ganho de produtividade gratuito para o trabalho diário com SQL.
Dê uma olhada nos índices vetoriais se você está fazendo RAG e atualmente rodando um vector store separado. Consolidar no Azure SQL significa um serviço a menos para gerenciar.

Concluindo

O anúncio completo tem mais — planos de economia, assistentes de migração, funcionalidades de conformidade — mas a história para desenvolvedores está no MCP Server, nas melhorias vetoriais e na camada de gestão agêntica. São essas as peças que mudam como você constrói, não apenas como você faz orçamento.

Confira o anúncio completo do Shireesh Thota para o panorama completo, e inscreva-se para o acesso antecipado ao Database Hub se quiser experimentar a nova experiência de gestão.

Azure DevOps MCP Server chega ao Microsoft Foundry: O que isso significa para seus agentes de IA

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

MCP (Model Context Protocol) está tendo seu momento. Se você tem acompanhado o ecossistema de agentes de IA, provavelmente notou servidores MCP surgindo por todo lado — dando aos agentes a capacidade de interagir com ferramentas e serviços externos através de um protocolo padronizado.

Agora o Azure DevOps MCP Server está disponível no Microsoft Foundry, e essa é uma daquelas integrações que faz você pensar nas possibilidades práticas.

O que está realmente acontecendo aqui

A Microsoft já lançou o Azure DevOps MCP Server como public preview — esse é o servidor MCP em si. A novidade é a integração com o Foundry. Agora você pode adicionar o Azure DevOps MCP Server aos seus agentes Foundry diretamente do catálogo de ferramentas.

Para quem ainda não conhece o Foundry: é a plataforma unificada da Microsoft para construir e gerenciar aplicações e agentes alimentados por IA em escala. Acesso a modelos, orquestração, avaliação, deploy — tudo em um só lugar.

Configurando

A configuração é surpreendentemente simples:

No seu agente Foundry, vá para Add Tools > Catalog
Busque “Azure DevOps”
Selecione o Azure DevOps MCP Server (preview) e clique em Create
Insira o nome da sua organização e conecte

Isso é tudo. Seu agente agora tem acesso às ferramentas do Azure DevOps.

Controlando o que seu agente pode acessar

Essa é a parte que eu aprecio: você não está preso a uma abordagem de tudo-ou-nada. Você pode especificar quais ferramentas estão disponíveis para seu agente. Então se você quer que ele apenas leia work items mas não toque em pipelines, pode configurar isso. Princípio do menor privilégio, aplicado aos seus agentes de IA.

Isso importa para cenários enterprise onde você não quer que um agente acidentalmente dispare um pipeline de deploy porque alguém pediu para ele “ajudar com o release.”

Por que isso é interessante para equipes .NET

Pense no que isso possibilita na prática:

Assistentes de planejamento de sprint — agentes que podem buscar work items, analisar dados de velocidade e sugerir capacidade de sprint
Bots de code review — agentes que entendem o contexto do seu PR porque podem realmente ler seus repos e work items vinculados
Resposta a incidentes — agentes que podem criar work items, consultar deploys recentes e correlacionar bugs com mudanças recentes
Onboarding de desenvolvedores — “No que devo trabalhar?” recebe uma resposta real baseada em dados reais do projeto

Para equipes .NET que já usam Azure DevOps para seus pipelines de CI/CD e gerenciamento de projetos, ter um agente de IA que pode interagir diretamente com esses sistemas é um passo significativo em direção à automação útil.

O panorama maior do MCP

Isso faz parte de uma tendência mais ampla: servidores MCP estão se tornando a forma padrão como agentes de IA interagem com o mundo exterior. Estamos vendo para GitHub, Azure DevOps, bancos de dados, APIs SaaS — e o Foundry está se tornando o hub onde todas essas conexões se encontram.

Se você está construindo agentes no ecossistema .NET, vale a pena prestar atenção ao MCP. O protocolo é padronizado, as ferramentas estão amadurecendo, e a integração com Foundry torna acessível sem precisar configurar manualmente conexões de servidor.

Para finalizar

O Azure DevOps MCP Server no Foundry está em preview, então espere que ele evolua. Mas o workflow principal é sólido: conectar, configurar acesso às ferramentas e deixar seus agentes trabalharem com seus dados de DevOps. Se você já está no ecossistema Foundry, está a poucos cliques. Experimente e veja quais workflows você consegue construir.

Confira o anúncio completo para a configuração passo a passo e mais detalhes.

Do laptop à produção: implantando agentes de IA no Microsoft Foundry com dois comandos

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

Você conhece aquela lacuna entre “funciona na minha máquina” e “está implantado e servindo tráfego”? Para agentes de IA, essa lacuna tem sido dolorosamente ampla. Você precisa provisionar recursos, implantar modelos, configurar identidade, montar monitoramento — e isso é antes de qualquer pessoa poder realmente chamar seu agente.

O Azure Developer CLI acabou de transformar isso em uma questão de dois comandos.

O novo fluxo de trabalho `azd ai agent`

Deixe-me mostrar como isso realmente se parece. Você tem um projeto de agente de IA — digamos um agente concierge de hotel. Funciona localmente. Você quer ele rodando no Microsoft Foundry.

azd ai agent init
azd up

Isso é tudo. Dois comandos. azd ai agent init gera a infraestrutura como código no seu repositório, e azd up provisiona tudo no Azure e publica seu agente. Você recebe um link direto para seu agente no portal Foundry.

O que acontece por baixo dos panos

O comando init gera templates Bicep reais e inspecionáveis no seu repositório:

Um Foundry Resource (contêiner de nível superior)
Um Foundry Project (onde seu agente vive)
Configuração de implantação de modelo (GPT-4o, etc.)
Identidade gerenciada com atribuições de papéis RBAC apropriadas
azure.yaml para o mapa de serviços
agent.yaml com metadados do agente e variáveis de ambiente

O ponto chave: tudo isso é seu. É Bicep versionado no seu repositório. Você pode inspecioná-lo, customizá-lo e fazer commit junto com o código do seu agente. Sem caixas pretas mágicas.

O ciclo interno de desenvolvimento

O que eu realmente gosto é a história de desenvolvimento local. Quando você está iterando na lógica do agente, não quer reimplantar toda vez que muda um prompt:

azd ai agent run

Isso inicia seu agente localmente. Combine com azd ai agent invoke para enviar prompts de teste, e você tem um ciclo de feedback apertado. Editar código, reiniciar, invocar, repetir.

O comando invoke também é inteligente no roteamento — quando um agente local está rodando, ele aponta automaticamente para ele. Quando não está, vai para o endpoint remoto.

Monitoramento em tempo real

Esta é a funcionalidade que me convenceu. Uma vez que seu agente está implantado:

azd ai agent monitor --follow

Cada requisição e resposta fluindo pelo seu agente é transmitida para seu terminal em tempo real. Para depurar problemas em produção, isso é inestimável. Sem vasculhar log analytics, sem esperar métricas agregarem — você vê o que está acontecendo agora.

O conjunto completo de comandos

Aqui a referência rápida:

Comando	O que faz
`azd ai agent init`	Gera um projeto de agente Foundry com IaC
`azd up`	Provisiona recursos Azure e implanta o agente
`azd ai agent invoke`	Envia prompts ao agente remoto ou local
`azd ai agent run`	Executa o agente localmente para desenvolvimento
`azd ai agent monitor`	Transmite logs em tempo real do agente publicado
`azd ai agent show`	Verifica saúde e status do agente
`azd down`	Limpa todos os recursos Azure

Por que isso importa para desenvolvedores .NET

Embora o exemplo do anúncio seja baseado em Python, a história de infraestrutura é agnóstica a linguagem. Seu agente .NET recebe o mesmo scaffolding Bicep, a mesma configuração de identidade gerenciada, o mesmo pipeline de monitoramento. E se você já usa azd para suas apps .NET Aspire ou implantações Azure, isso se encaixa direto no seu fluxo de trabalho existente.

A lacuna de implantação para agentes de IA tem sido um dos maiores pontos de fricção no ecossistema. Ir de um protótipo funcional a um endpoint de produção com identidade, rede e monitoramento adequados não deveria exigir uma semana de trabalho DevOps. Agora requer dois comandos e alguns minutos.

Para finalizar

azd ai agent está disponível agora. Se você tem adiado a implantação dos seus agentes de IA porque a configuração de infraestrutura parecia trabalho demais, experimente. Confira o tutorial completo para o passo a passo completo incluindo integração de app de chat frontend.

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.

Emiliano Montesdeoca

Mon, 01 Jan 0001 00:00:00 +0000

Escreva para The .NET Blog

Mon, 01 Jan 0001 00:00:00 +0000

#The .NET Blog uma publica o impulsionada pela comunidade onde desenvolvedores compartilham insights, tutoriais e histrrrias sobre .NET, Azure, IA e desenvolvimento cloud-native. Recebemos contribuieeeees de desenvolvedores de todos os seja vocNeis escrevendo seu primeiro artigo t cnico ou um palestrante experiente.

Como Participar

Tudo fica no GitHub e segue um fluxo de trabalho com pull requests. Veja como comear:

1. Faa um Fork do Repositrrrio

Acesse github.com/thedotnetblog/blog e faa um fork para sua conta do GitHub.

2. Crie seu Perfil de Autor

#Se esta sua primeira contribui o, adicione-se como autor criando uma pasta em content/authors/seu-usuario/ com um arquivo index.md:

---
title: "Seu Nome"
id: "seu-usuario"
role: "Seu cargo ou tulo"
bio: "Uma breve biografia sobre voc."
avatar: "/img/authors/seu-avatar.jpg"
socials:
 - platform: "GitHub"
 url: "https://github.com/seu-usuario"
 - platform: "Twitter"
 url: "https://x.com/seu-usuario"
---

Adicione sua imagem de avatar (quadrada, mimo 200200px) em static/img/authors/.

3. Escreva seu Artigo

Crie uma nova pasta em content/posts/seu-usuario/slug-do-seu-artigo/ e adicione um arquivo index.md:

---
title: "Tulo do seu Artigo"
date: 2025-01-01
author: "seu-usuario"
#description: "Uma descri
o em uma frase do seu artigo."
tags: ["dotnet", "azure"]
---

O contedo do seu artigo em Markdown...

4. Abra um Pull Request

Envie suas alteraeeeees para o seu fork e abra um pull request contra a branch main. Nossa equipe vai revisar e dar feedback em poucos dias.

O que Buscamos

** guias passo a passo sobre .NET, Azure, IA, Blazor, Aspire e maisTutoriais** #- Anlises exploraAprofundadas eeeees detalhadas de uma tecnologia, padr o ou arquitetura #- Histrrrias da sua experiComunidadencia construindo com .NET em produ o
Resumos de resumos de conferEventosncias, meetups ou webinars

Diretrizes

O contedo deve ser tcnico e relevante para o ecossistema .NET
Exemplos de cdddigo devem ser precisos e testados em um projeto real #- Inclua uma descri o significativa e pelo menos uma tag relevante #- Os artigos s o traduzidos automaticamente para todos os idiomas suportados

Contato

Abra uma issue no GitHub ou entre em contato no X / Twitter. Adorarmos themes -lo na comunidade!

The .NET Blog

NDC Oslo 2026

Em números

Palestrantes confirmados

Ingressos

Outros eventos NDC em 2026

Links

.NET Day Switzerland 2026

O que você recebe

Ingressos

Organizadores

Links

SDD Conference 2026

Tópicos

Palestrantes

Ingressos e informações

Atualização de Abril do Azure DevOps MCP Server: Consultas WIQL, Auth PAT e MCP Apps Experimental

Suporte a Consultas WIQL

Personal Access Tokens

Anotações MCP

Consolidação das Ferramentas Wiki

Experimental: MCP Apps

SQL Server 2025 como Banco de Dados Pronto para Agentes: Segurança, Backup e MCP em Um Motor

Um Modelo de Segurança para Todos os Modelos de Dados

Backup Unificado = Recuperação Atômica

Integração MCP: Agentes Sem Middleware

.NET 10 Vem com Ubuntu 26.04 LTS — O que há de Novo

Instale .NET 10 em dois comandos

Contêineres: atualize -noble para -resolute

Native AOT: inicialização em 3ms, binário de 1,4MB

Precisa de .NET 8 ou 9?

Azure SDK Abril 2026: AI Foundry 2.0 e o Que Desenvolvedores .NET Devem Saber

Azure.AI.Projects 2.0.0 — Breaking Changes que Fazem Sentido

Cosmos DB Java: Correção Crítica de Segurança (RCE)

Novas Bibliotecas de Provisioning para .NET

CodeAct no Agent Framework: Como Reduzir a Latência do seu Agente pela Metade

O que é CodeAct?

A peça de segurança: Micro-VMs do Hyperlight

Configuração mínima

Quando usar o CodeAct (e quando não usar)

Experimente agora

GPT-5.5 Chegou ao Azure Foundry — O que Desenvolvedores .NET Precisam Saber

A progressão do GPT-5

O que realmente mudou

Preços

Por que o Foundry importa

O Azure MCP Server Agora é um .mcpb — Instale-o sem Nenhum Runtime

O que é um MCP Bundle?

Como instalar

O que você pode fazer

Para começar

Onde seu Agente se Lembra das Coisas? Guia Prático de Armazenamento do Histórico de Chat

Dois padrões fundamentais

Como o Agent Framework abstrai isso

Referência rápida de provedores

Como escolher

VS Code 1.118: Copilot CLI Ganha Nomes de Sessão, Badges de Modelo e TypeScript 7.0 Nightly

Copilot CLI: sessões têm nomes reais

Troque de sessão mais rápido

Badges de modelo no chat

Seleção automática de modelo no Copilot CLI

Opt-in para TypeScript 7.0 Nightly

Aspire 13.2: Suporte a Bun, Melhores Contêineres e Menos Fricção no Debug

Bun é Agora Cidadão de Primeira Classe

Yarn Ficou Mais Confiável

Melhorias em Contêineres

Melhorias de Debug

68 Minutos por Dia Re-Explicando Código? Existe uma Solução

A Mentira da Janela de Contexto

O Imposto de Compactação

auto-memory: Uma Camada de Recall, Não um Sistema de Memória

Conclusão

Foundry Toolboxes: Um único endpoint para todas as ferramentas dos seus agentes

O que é um Toolbox?

Os quatro pilares (dois disponíveis hoje)

Exemplo prático

Sem lock-in no Foundry Agents

Por que importa agora

Conclusão

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

Contêineres: atualize `-noble` para `-resolute`