Aspire | The .NET Blog

Endpoints Privados, VNets, NSGs — Aspire Gerencia a Rede Agora

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

Já vi esse cenário muitas vezes. A aplicação está pronta. A demonstração é ótima. Então aparece a lista de verificação de segurança: tire o armazenamento da internet pública, execute dentro de uma VNet, forneça IPs de saída para a lista de permissões do parceiro, prove que apenas as sub-redes corretas falam com os serviços corretos.

Nesse ponto o modelo de aplicação e o modelo de infraestrutura começam a divergir de maneiras que são dolorosas de manter.

O novo suporte de rede empresarial do Azure para Aspire aborda isso diretamente. Você descreve a forma da rede ao lado dos recursos que a usam, no seu AppHost.

Os Blocos de Construção

Aqui está para que serve cada conceito de rede do Azure, destilado:

Recurso	Use quando	Por que é importante
Rede virtual	Você precisa de um espaço de endereçamento privado	O limite de rede para sub-redes, endpoints privados e roteamento
Sub-rede	Você precisa separar cargas de trabalho dentro da VNet	Cada parte do sistema obtém seu próprio intervalo de endereços e superfície de política
Sub-rede delegada	Um serviço de plataforma (como ACA) precisa gerenciar uma sub-rede	Permite que o serviço coloque infraestrutura gerenciada em sua VNet com segurança
Gateway NAT	Você precisa de IPs públicos de saída previsíveis	Endereço estável para listas de permissões e auditoria
Endpoint privado	Você quer um recurso PaaS acessível privatamente	Coloca um IP privado para esse serviço dentro da sua VNet, remove a exposição pública
NSG	Você precisa de regras de tráfego no nível da sub-rede	Permitir/negar explícito para tráfego de entrada e saída por sub-rede

Descrevendo no seu AppHost

A mudança chave aqui é que você está modelando a rede junto com os recursos que a usam, não em um arquivo Bicep separado que se afasta do modelo de aplicação com o tempo.

Do AppHost, você pode:

Criar VNets e sub-redes com AddVirtualNetwork() e AddSubnet()
Anexar um gateway NAT às sub-redes para IPs de saída estáveis
Criar endpoints privados para armazenamento, Key Vault, SQL e outros serviços PaaS
Definir NSGs com regras de segurança de entrada e saída
Configurar Perímetros de Segurança de Rede para políticas entre recursos

O resultado é que quando você executa azd up, a infraestrutura corresponde ao que o modelo de aplicação diz que precisa. Não o que diz um template mantido manualmente.

Por Que Isso Importa para Aplicações Reais

Algumas coisas que se tornam significativamente mais fáceis quando a rede é modelada no Aspire:

Endpoints privados para Key Vault e armazenamento — você descreve WithPrivateEndpoint() nesses recursos, e o Aspire lida com a configuração da zona DNS e o anexo de endpoints. A aplicação nunca muda.

IPs de saída consistentes — adicione um gateway NAT à sub-rede relevante e cada solicitação de saída da sua aplicação passa por um IP conhecido e estável. Os parceiros podem incluí-lo na lista de permissões. Os auditores podem rastreá-lo.

Regras NSG do código — em vez de clicar no portal ou manter um trecho Bicep, suas regras de segurança vivem no AppHost ao lado dos recursos que protegem.

Este é o tipo de integração que não torna as demonstrações emocionantes, mas torna os sistemas de produção manuteníveis.

Conclusão

A segurança de rede aparecendo tarde no ciclo de vida do projeto é um problema resolvido se você a modelar junto com a aplicação desde o início. O suporte de rede empresarial do Aspire torna isso possível sem exigir um rastreamento de infraestrutura separado.

Detalhes completos na publicação original: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Suporte ao Kubernetes, Logs do Navegador e a Skill Aspireify

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Cinco semanas não é muito tempo para um lançamento, mas o Aspire 13.3 não parece assim. Os itens principais são significativos: implantação de Kubernetes e AKS de primeira classe com Helm, uma skill de integração assistida por agente chamada Aspireify, captura de logs do navegador diretamente no dashboard e resultados de comandos estruturados. Além disso, 45 novos recursos, 134 melhorias e 93 correções de bugs.

Vamos aos destaques.

Aspireify: Integração Assistida por Agente

Adicionar o Aspire a um projeto existente parece simples — coloque um AppHost, pronto. Na prática, envolve muita arqueologia: quais portas importam, quais variáveis de ambiente são dependências reais, quais serviços do Docker Compose devem ser mapeados para integrações do Aspire.

A nova skill Aspireify fornece ao seu agente de código um fluxo de trabalho guiado exatamente para isso. Quando aspire init cria um AppHost esqueleto, a skill Aspireify ajuda o agente a inspecionar o repositório, entender como já funciona e conectar o AppHost para se adaptar ao aplicativo — não o contrário.

A postura padrão é “minimizar alterações no seu código.” Se o seu aplicativo já lê DATABASE_URL, o agente mapeia isso com WithEnvironment() em vez de pedir que você reescreva sua configuração. Se uma porta está codificada de forma fixa, a skill indica ao agente quando preservá-la.

Este é o tipo de tooling de IA que realmente economiza tempo em vez de gerar mais trabalho para revisar.

Implantação de Kubernetes e AKS de Primeira Classe

Esta estava na lista de desejos há algum tempo. O Aspire 13.3 inclui suporte de implantação de Kubernetes e AKS de primeira classe com Helm. Agora você pode direcionar o AKS como destino de implantação diretamente das ferramentas do Aspire.

Para equipes que já executam cargas de trabalho de produção no AKS, isso fecha uma lacuna significativa. Seu modelo de aplicativo Aspire agora tem um caminho limpo do desenvolvimento local ao Kubernetes sem a necessidade de escrever manualmente charts Helm.

Logs do Navegador no Dashboard

Esta é uma daquelas funcionalidades que parecem pequenas até você estar depurando um problema de frontend.

A nova API WithBrowserLogs() anexa um recurso de navegador rastreado a qualquer recurso capaz de endpoints. O Aspire lança o Chromium usando um pipe CDP privado e transmite logs do console, solicitações de rede e erros diretamente no fluxo de logs do recurso:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

O AppHost TypeScript suporta o mesmo:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Erros de console, solicitações de rede com falha, exceções do lado do cliente — tudo visível no mesmo dashboard onde você já está observando traces e métricas. Sem necessidade de trocar de aba para o DevTools do navegador para as coisas básicas.

Resultados de Comandos Estruturados

Os comandos de recursos receberam uma atualização significativa. Até agora, os comandos retornavam sucesso/falha. Agora eles retornam resultados estruturados: texto, JSON ou markdown que flui pelo modelo, pela interface do dashboard, pela CLI e pelas ferramentas MCP.

O dashboard une tudo isso com um novo centro de notificações no cabeçalho. Os resultados dos comandos aparecem como notificações com carimbo de data/hora com renderização de markdown e uma ação “Ver resposta”.

Isso torna os comandos de recursos verdadeiramente combináveis. Uma integração agora pode expor um comando que retorna uma saída significativa — como uma URL de túnel — em vez de simplesmente alterar o estado em algum lugar.

Conclusão

O Aspire 13.3 vale a atualização mesmo que seja apenas pelo suporte ao Kubernetes. Os logs do navegador e os resultados de comandos estruturados parecem o tipo de melhorias de qualidade de vida que se acumulam rapidamente em um fluxo de trabalho de desenvolvimento diário.

Notas de versão completas: What’s New in Aspire 13.3

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.

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.

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

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

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.

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

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

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

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.

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

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

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.

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

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

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.

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

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

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.

Aspire | The .NET Blog

Endpoints Privados, VNets, NSGs — Aspire Gerencia a Rede Agora

Os Blocos de Construção

Descrevendo no seu AppHost

Por Que Isso Importa para Aplicações Reais

Conclusão

Aspire 13.3: Suporte ao Kubernetes, Logs do Navegador e a Skill Aspireify

Aspireify: Integração Assistida por Agente

Implantação de Kubernetes e AKS de Primeira Classe

Logs do Navegador no Dashboard

Resultados de Comandos Estruturados

Conclusão

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

Global Azure Spain 2026

Destaques da agenda

Ingressos

Azure Tour 2026

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

Modo desacoplado: um comando, terminal de volta

Gerenciando o que está rodando

Combine com o modo isolado

Por que isso é enorme para agentes de código

Finalizando

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

O problema é real

Aspire como infraestrutura para agentes

A analogia dos para-choques de boliche

Primeiros passos

Concluindo

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

A solução: --isolated

Cenários reais onde isso brilha

Como funciona internamente

Quando usar

Concluindo

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

O problema que isso realmente resolve

Três comandos, zero abas do navegador

Listar todos os docs

Pesquisar um tópico

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

O ângulo do agente de IA

Cenários do mundo real

A documentação está sempre atualizada

Pra fechar

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

Exportar telemetria de forma civilizada

A API de telemetria é o verdadeiro divisor de águas

Telemetria GenAI fica prática

Conclusão

A solução: `--isolated`