Introdução ao Aspire 9.5 - Comece rapidamente com esta ferramenta essencial

Primeiros passos e instalação do Aspire 9.5

Tim começa explicando a finalidade do Aspire. Todo desenvolvedor .NET que cria APIs ou aplicativos web deve entender essa ferramenta essencial da Microsoft. Houve confusão sobre o que o Aspire pode fazer, então Tim decide demonstrar seu propósito, configuração e uso desde o início.

Ele abre o Visual Studio e inicia um novo projeto usando o modelo de aplicativo inicial Aspire. Caso você não tenha o Aspire instalado, ele indica o site da Microsoft para obter informações sobre a configuração e as ferramentas do Aspire, observando que você pode instalá-lo por meio da CLI do .NET , do Visual Studio ou do VS Code. Para maior simplicidade, Tim recomenda o uso do comando da CLI:

dotnet new install aspire.templates

Isso instala os modelos de projeto mais recentes, incluindo o Aspire 9.5. Após a instalação, o Visual Studio pode precisar ser reiniciado para que os modelos apareçam.

Tim seleciona o aplicativo de demonstração Aspire, escolhe o .NET 9, habilita o HTTPS e usa a integração com o Redis para o armazenamento em cache. Isso demonstra um cenário do mundo real onde o Aspire gerencia um aplicativo inteiro localmente. Ele ignora os testes unitários e prossegue com a criação dos arquivos de solução.

Explorando a estrutura do projeto e o modelo do aplicativo

Após a geração do projeto, Tim analisa os arquivos criados pelo modelo de aplicativo da Aspire. A solução inclui quatro projetos principais que refletem tanto projetos típicos do .NET quanto projetos específicos do Aspire:

1. Projeto Web – uma aplicação web baseada em Blazor.

2. Serviço de API – um serviço de backend para dados ou lógica de negócios.

3. AppHost – o AppHost de arquivo único que inicia todo o aplicativo.

4. ServiceDefaults – uma biblioteca que contém verificações de integridade, descoberta de serviços e configuração de telemetria.

Os dois primeiros representam um sistema distribuído normal (frontend e backend), enquanto os outros dois representam o conjunto de ferramentas unificado do Aspire para gerenciar variáveis ​​de ambiente, dependências e APIs de eventos do ciclo de vida de recursos.

Tim destaca como esse novo modelo de aplicativo oferece suporte de primeira classe para orquestração de múltiplos projetos, permitindo que os desenvolvedores executem todo o aplicativo com um único comando. O AppHost controla a ordem de inicialização e as dependências, enquanto o ServiceDefaults injeta automaticamente configurações padrão, verificações de integridade e integração de telemetria.

Por que a Aspire simplifica o desenvolvimento local?

Tim explica as dificuldades de gerenciar um sistema distribuído localmente sem o Aspire. Tradicionalmente, os desenvolvedores precisam configurar manualmente os ambientes de execução de contêineres, o encaminhamento de portas e as strings de conexão para cada serviço. Cada desenvolvedor deve replicar individualmente as variáveis ​​de ambiente, os segredos do usuário e as conexões Redis ou de API.

Com o Aspire, a CLI do Aspire lida com isso automaticamente. Ele inicia dependências como contêineres Redis por meio de um contêiner de desenvolvimento ou instância Docker, gerencia a descoberta de endpoints e fornece acesso privado entre serviços usando a descoberta de serviços.

O Aspire utiliza um proxy reverso e um sistema de resolução de endpoints, de forma que o frontend da web não precise conhecer números de porta fixos. Simplesmente se refere à API pelo nome (como "apiservice") — o Aspire se encarrega do resto.

Isso melhora drasticamente a experiência do desenvolvedor, eliminando etapas de configuração tediosas e permitindo que ele se concentre no código, e não na infraestrutura.

Definindo serviços e dependências no AppHost

Tim mostra o núcleo da configuração do Aspire: o arquivo Program.cs do AppHost. Usando um padrão de construtor de variáveis, o Aspire define cada serviço com comandos simples como:

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.ApiService>("apiservice");
var web = builder.AddProject<Projects.Web>("webfrontend")
    .WithReference(cache)
    .WithReference(api);

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.ApiService>("apiservice");
var web = builder.AddProject<Projects.Web>("webfrontend")
    .WithReference(cache)
    .WithReference(api);

Essa sintaxe define cada recurso, estabelece a ordem de dependência e cria um ciclo de vida claro para os recursos. O Aspire lida automaticamente com a espera por dependências, garantindo que o cache seja iniciado primeiro, depois a API e, por fim, o frontend da web.

Este pequeno conjunto de instruções oferece aos desenvolvedores um controle preciso sobre o comportamento de inicialização, espelhando como as coisas funcionariam em aplicativos distribuídos prontos para produção.

Executando o Aspire e entendendo o painel de controle.

Quando Tim executa o projeto, o Aspire inicia seu próprio ambiente de execução de contêiner e abre o Painel do Aspire — uma interface central para monitorar tudo. Inicialmente, aparece um erro: "Tempo de execução do contêiner não íntegro" — o Docker não estava em execução. Assim que o Docker é iniciado, o Aspire inicializa automaticamente um recurso executável do Redis e o conecta ao restante do aplicativo.

O painel exibe ícones de status com códigos de cores, indicando o estado de cada recurso. Assim que o Redis, a API e a interface web estiverem em execução, o painel de controle ficará verde, indicando que todo o aplicativo está funcionando corretamente.

Este sistema de notificação reflete instantaneamente os estados em tempo real, fornecendo mensagens de erro mais claras do que os registros padrão do console. Os desenvolvedores podem visualizar relacionamentos de serviço, monitorar métricas e até mesmo acessar endpoints de recursos diretamente da interface do usuário.

Informações visuais através do painel Aspire

A visualização em gráfico no painel mostra como os serviços se conectam. Por exemplo, a interface web se conecta tanto ao Redis quanto ao serviço de API, enquanto a API é independente. Essa visualização de rastreamento ajuda a entender o fluxo interno de chamadas e dependências.

Tim destaca que o painel inclui melhorias nos detalhes do rastreamento, como a exibição de opções de filtragem de rastreamento e detalhamento de tempo. Os desenvolvedores podem rastrear solicitações HTTP em todos os serviços e visualizar os impactos no desempenho usando a visualização de rastreamento do Aspire.

Registro centralizado e registros estruturados

O Aspire unifica os registros do console de todos os arquivos do projeto em uma única visualização. Em vez de gerenciar várias janelas de registro, os desenvolvedores podem usar o painel para visualizar os registros de todos os serviços — aplicativo web, API e integração com Redis — em uma única linha do tempo.

Tim demonstra que o Aspire utiliza registro estruturado, permitindo entradas ricas em contexto, como IDs, parâmetros e tags. Os desenvolvedores podem filtrar os registros por nível (Informação, Aviso, Erro) ou por valores de propriedade.

Por exemplo, um desenvolvedor pode visualizar apenas as entradas em que "evenOddResult" == "odd". Essa filtragem avançada de logs, combinada com os prefixos codificados por cores do Aspire, torna a depuração intuitiva e visual.

Trabalhando com rastreamento e telemetria

Na aba Rastreamentos, Tim demonstra como o Aspire rastreia solicitações em todos os serviços do aplicativo. Cada rastreamento contém informações de tempo, status e intervalos, mostrando qual serviço processou o quê.

Por exemplo, uma solicitação "GetWeather" mostra quando o cache foi encontrado ou não, quando a chamada da API ocorreu e quanto tempo cada ação levou. Essa filtragem de rastreamento permite a identificação precisa de gargalos e dependências.

O Aspire também oferece suporte ao OpenTelemetry para exportar dados de rastreamento para outras ferramentas ou sistemas, proporcionando aos desenvolvedores total visibilidade em serviços distribuídos.

Métricas em tempo real e monitoramento de desempenho

Tim explora métricas como duração das requisições, conexões ativas do SignalR e número de requisições ativas. Essas métricas visualizam o estado em tempo real do seu aplicativo e permitem a detecção precoce de problemas de conexão ou latência.

Os dados de métricas no Aspire 9.5 também se beneficiam de melhorias nos detalhes de rastreamento e de uma filtragem de rastreamento aprimorada, permitindo que os desenvolvedores identifiquem em tempo real onde ocorrem quedas de desempenho.

Aspire é para o desenvolvimento local, não para a produção.

Tim deixa claro que o painel de controle do Aspire não foi projetado para ser implantado em servidores de produção. A implementação exporia detalhes internos do sistema e variáveis ​​de ambiente, o que poderia ser arriscado.

No entanto, os desenvolvedores ainda podem usar o comando aspire deploy do Aspire para publicar serviços no Azure Container Apps, no Azure Container App Jobs ou em outras integrações do Aspire. Essas opções de implantação estão crescendo, mas permanecem separadas do painel de controle.

O objetivo do Aspire é espelhar localmente um ambiente semelhante ao de produção, com atualizações seguras e suporte a versões prévias, e não substituir os sistemas de monitoramento de produção.

Experimentando com registro de logs e tratamento de exceções

Tim adiciona registro estruturado na página de Contador e introduz deliberadamente uma exceção NotImplementedException na página de Clima. Ao executar novamente, o painel de controle captura imediatamente tanto os registros estruturados quanto as exceções não tratadas.

Ele mostra como os registros do Aspire exibem detalhes completos, incluindo o nome do parâmetro, os valores e a pilha de chamadas. A integração com o GitHub Models e o Copilot AI permite explicações automáticas de exceções e sugestões de código para correções — um exemplo de integração inicial de serviços de IA e visualizadores de IA generativa na experiência do desenvolvedor.

Analisando erros com filtragem de rastreamento

Na aba Rastreamentos, Tim demonstra como as chamadas de API com falha são exibidas com ícones de exclamação vermelhos. Clicar em um deles revela todos os registros relacionados, filtrados por ID de intervalo, vinculando cada solicitação em vários projetos .NET .

Essa visão unificada — que combina registros, rastreamentos e verificações de integridade — fornece instruções interativas para depuração e criação de sistemas observáveis ​​sem configuração externa.

Integrando o Aspire em projetos .NET existentes

Tim explica então como integrar o Aspire a um aplicativo existente. Os desenvolvedores precisam adicionar apenas duas coisas:

• O projeto AppHost, que controla quais serviços são iniciados e suas dependências.

• O projeto ServiceDefaults, que fornece sinalizadores de recursos, verificações de integridade, telemetria e descoberta de serviços.

Ao referenciar o ServiceDefaults em cada arquivo de projeto, os desenvolvedores obtêm automaticamente variáveis ​​de ambiente padrão, configuração de registro e telemetria. O sistema de resolução de endpoints da Aspire elimina a necessidade de encaminhamento manual de portas ou gerenciamento de strings de conexão.

Expandindo o Aspire para além do uso local

Tim explica como as capacidades do Aspire estão se expandindo para além do uso local. Com as integrações do Azure Container Apps e do Azure AI Foundry, os desenvolvedores podem usar a CLI do Aspire para implantar sistemas distribuídos com configuração mínima.

O sistema já oferece suporte a ícones de recursos personalizados, propriedades de nome e visualização prévia para serviços de IA, como endpoints do OpenAI ou conexões do Azure PostgreSQL.

O conjunto de ferramentas unificado do Aspire também oferece suporte ao controle de versões e atualizações seguras entre versões principais e secundárias, ajudando as equipes a adotar atualizações como o Aspire 9.5 com confiança.

Considerações finais e perspectivas futuras

Ao concluir o vídeo , Tim chama o Aspire de "uma mina de ouro para desenvolvedores". O painel combina visualização de rastreamento, verificações de integridade, registros e métricas em um único painel unificado — algo que antes não estava disponível no desenvolvimento local.

Para Tim e sua equipe, todo novo projeto .NET Aspire agora usa esse sistema por padrão. Isso torna as compilações personalizadas mais rápidas, melhora a experiência do desenvolvedor e garante que os aplicativos distribuídos prontos para produção se comportem de maneira consistente em todas as máquinas.

Ele observa que as principais versões do Aspire continuarão a aprimorar a filtragem de rastreamento, a resolução de endpoints e as integrações de IA, mantendo o foco em atualizações seguras e disponibilidade geral.

Tim incentiva todos a explorarem o Aspire 9.5, usá-lo em seus próximos projetos .NET e aproveitar sua simplicidade de comando único para visualizar logs, gerenciar túneis de desenvolvimento e testar todo o aplicativo localmente com confiança.