Developer Tools | The .NET Blog

VS Code 1.119: OpenTelemetry para Sessões de Agentes, Integração do Navegador e Segurança

Emiliano Montesdeoca — Fri, 15 May 2026 00:00:00 +0000

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

VS Code 1.119 foi lançado em 6 de maio de 2026 (com um patch de segurança 1.119.1 logo em seguida). O lançamento se concentra em observabilidade de agentes, interação com o navegador e redução de interrupções.

Rastreamento OpenTelemetry para sessões de agentes

Este é o recurso de destaque para quem executa agentes em produção ou depura fluxos de trabalho agênticos. Ative com duas configurações:

"github.copilot.chat.otel.enabled": true,
"github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318"

Os rastros seguem as convenções semânticas GenAI. Cada solicitação do agente produz um span raiz invoke_agent com spans filho aninhados: chat, execute_tool e execute_hook. O uso de tokens é relatado por solicitação — incluindo contagens de leitura e criação de cache.

Funciona com o agente local, o agente em segundo plano do Copilot CLI e o agente Claude. Qualquer backend compatível com OTLP aceita os rastros — o Aspire Dashboard standalone funciona bem para desenvolvimento local.

Agentes agora podem acessar abas do navegador

Os agentes podem solicitar acesso às abas do navegador integrado — mas não é automático. Você deve compartilhar explicitamente uma aba via seletor de contexto, arrastar e soltar, ou contexto sugerido. Há um botão de compartilhamento no navegador para revogar o acesso. Quando um agente tenta abrir uma nova aba no mesmo domínio que uma aba já aberta (não compartilhada), o VS Code solicita que você reutilize a aba existente.

Uso otimizado de tokens

Um modelo leve experimental agora gerencia as listas de tarefas dos agentes, mantendo esse trabalho administrativo longe do modelo principal mais caro. Reduz o consumo de tokens para tarefas que não precisam de capacidade completa de raciocínio.

Confiança e segurança

Menos interrupções: VS Code 1.119 reduz solicitações de acesso à rede e gravações em pastas temporárias por agentes. O patch 1.119.1 resolve problemas de segurança específicos — vale a pena atualizar se ainda não o fez.

Troca rápida para pré-visualização Markdown

Pequeno mas útil: agora você pode trocar rapidamente o editor atual para a pré-visualização Markdown sem navegar.

VS Code Agents (pré-visualização Insiders)

A interface de sessão de agentes redesenhada — novo seletor de repositórios (local/repos/remoto), melhorias de subsessões, refinamento web e mobile, animações de progresso — está disponível no Insiders em insiders.vscode.dev/agents.

Changelog completo: code.visualstudio.com/updates/v1_119.

Azure Data Studio foi descontinuado: migre seu fluxo de Azure SQL para o VS Code

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

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

Azure Data Studio foi descontinuado em 6 de fevereiro de 2025, com suporte até 28 de fevereiro de 2026 — o substituto recomendado é o VS Code com a extensão MSSQL.

O que instalar

Três itens para começar:

Extensão MSSQL — pesquise “SQL Server (mssql)” no Marketplace do VS Code
Extensão SQL Database Projects — esquema como código, validação de build, publicação guiada
.NET 8 SDK — exigido pelo sistema de build; SDK ausente é o problema mais comum no primeiro uso

Migrar suas conexões e configurações do ADS

A extensão MSSQL inclui o ADS Migration Toolkit, que gerencia a migração única em um fluxo guiado: conexões salvas, grupos de conexões, configurações e atalhos de teclado são importados automaticamente.

Recuperar a memória muscular do F5

Os usuários do ADS dependem do F5 para executar consultas. Instale a extensão MSSQL Database Management Keymap para recuperar os atalhos de teclado no estilo ADS, incluindo o F5.

SQL Database Projects: esquema como código

Clique com o botão direito em um projeto → Publicar → configurar destino → revisar o script T-SQL gerado → implantar. A visualização prévia do script antes da implantação é o principal recurso de segurança. Os modelos de itens geram stubs para tabelas, stored procedures e views — o mesmo fluxo do SSDT.

Problema comum: uma incompatibilidade de plataforma de destino no arquivo .sqlproj causará erros de build se o projeto foi criado para uma versão diferente do SQL Server.

Schema Compare e Schema Designer

A extensão também inclui Schema Compare (diff entre seu projeto e o banco de dados implantado) e Schema Designer (edição visual do esquema sem escrever DDL manualmente).

Desenvolvedores do Microsoft Fabric

A configuração é idêntica, mas comece pelo portal do Fabric e conecte o banco de dados ao Git primeiro antes de abri-lo no VS Code. A Microsoft tem um guia dedicado: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

Conclusão

A migração é um fluxo guiado de uma única vez, não uma reconstrução manual. Instale as três ferramentas, execute o ADS Migration Toolkit, restaure seus atalhos de teclado e você estará de volta ao normal em menos de 10 minutos.

Consulte o artigo completo para capturas de tela passo a passo e o tutorial específico do Fabric.

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.

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.

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.

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.

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.

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.

.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.

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.

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.

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.

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.

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.

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.