Cli | The .NET Blog

dotnet new WinUI : Créer des apps Windows sans toucher à Visual Studio

Emiliano Montesdeoca — Wed, 27 May 2026 00:00:00 +0000

Le développement WinUI nécessitait auparavant Visual Studio. Cela est en train de changer : Microsoft a publié des modèles de projets et d’éléments open source pour WinUI qui fonctionnent avec dotnet new, intégrant le développement d’applications Windows dans le workflow standard de la CLI.

Démarrer en trois commandes

# Installer les modèles
dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates

# Créer une app NavigationView
dotnet new winui-navview -n MyApp

# L'exécuter
cd MyApp
dotnet run

Pas de Visual Studio, pas de configuration manuelle du projet. L’application s’exécute avec dotnet run.

Ce qui est inclus

Modèle vierge (dotnet new winui) — un point de départ moderne avec une barre de titre Fluent déjà configurée, une icône d’app mise à jour avec un asset .ico, et des valeurs par défaut correctes pour le mode clair/sombre. Mieux que l’ancien modèle vierge qui vous laissait configurer les bases vous-même.

Modèle NavigationView (dotnet new winui-navview) — le modèle de navigation maître-détail, entièrement configuré avec un NavigationView, une barre de titre moderne et une structure de navigation multi-pages. Suit la silhouette standard des apps Windows pour les applications basées sur la navigation. Si vous construisez quelque chose avec une navigation latérale, commencez ici.

Les deux modèles suivent les silhouettes d’apps Windows — des modèles Fluent Design modernes pour la mise en page, la navigation et la structure visuelle — dès le départ.

Pourquoi c’est important pour les développeurs qui n’utilisent pas Visual Studio

Les développeurs WinUI utilisant VS Code, Rider ou les outils en ligne de commande ont été mal servis. Les modèles Visual Studio existants n’étaient pas utilisables en dehors de VS — il fallait recréer manuellement la structure du projet et configurer les bases.

Ces modèles sont open source (voir WindowsAppSDK PR #6407), développés à partir des retours de la communauté, et disponibles maintenant. Le support Visual Studio est en cours — ces mêmes modèles fonctionneront également là-bas à terme.

Pour les équipes qui veulent automatiser la configuration de leurs projets WinUI, l’intégrer dans la CI, ou simplement utiliser un éditeur autre que Visual Studio, c’est une amélioration significative.

Post original : Introducing dotnet new WinUI templates

Cosmos DB Shell Est en Préversion Publique — Et Il a un Serveur MCP Intégré

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

Si vous avez déjà dû naviguer entre un onglet de portail, un exemple de SDK et un script à moitié terminé juste pour répondre à une question Cosmos DB, vous connaissez déjà la friction que ce projet est conçu pour éliminer.

Azure Cosmos DB Shell vient d’entrer en préversion publique. C’est un CLI open source avec une syntaxe de type bash et — la partie qui le rend intéressant — un serveur MCP intégré.

Ce Qui le Différencie des Autres CLIs de Base de Données

Le CLI lui-même est utile : commandes familières, support de script, intégration CI/CD. Cette partie est le minimum attendu pour un outil de base de données orienté développeur.

La partie intéressante est l’intégration du serveur MCP. Chaque commande que le CLI expose devient disponible comme outil MCP que vos agents IA peuvent appeler. Il n’y a pas de couche API personnalisée, pas de code d’intégration à écrire. Votre agent peut :

Naviguer dans les hiérarchies de bases de données avec cd, ls, pwd
Exécuter des requêtes SQL avec query et obtenir des résultats structurés
Créer et modifier des éléments avec create item, update, rm
Gérer des bases de données et des conteneurs avec mkdb, mkcon, rmdb, rmcon
Inspecter le contexte actuel avec endpoint, pwd

Le changement clé : votre agent ne parle pas à une API Cosmos DB — il parle à la même interface shell que vous utilisez. Les commandes sont déterministes, auditables et open source pour que vous puissiez inspecter exactement ce qui se passe.

La Base Open Source Compte

Ce n’est pas un service géré boîte noire. Le shell est open source, ce qui signifie :

Les équipes de sécurité peuvent auditer l’implémentation
Les équipes de plateforme peuvent le forker et l’étendre pour leurs standards spécifiques
Les développeurs peuvent contribuer des améliorations qui bénéficient à tous

Pour les équipes d’entreprise adoptant des outils IA, “peut-on voir exactement comment ça fonctionne” est de plus en plus une exigence non optionnelle. L’open source ici est un différenciateur significatif.

Trois Scénarios Qui Deviennent Plus Faciles

Analyse intelligente des données — connectez un agent au shell, posez des questions en langage naturel, obtenez des résultats de requêtes structurés. L’agent gère la construction de la requête ; le shell gère l’exécution.

Gestion autonome des données — les workflows qui doivent créer, mettre à jour ou supprimer des données dans Cosmos DB peuvent le faire via les outils MCP sans avoir besoin d’une intégration personnalisée.

Surveillance et alertes en temps réel — un agent peut interroger périodiquement des conteneurs, comparer les résultats et signaler des anomalies via le canal de notification approprié.

L’interface MCP rend ces scénarios composables avec n’importe quelle plateforme IA qui parle MCP — pas seulement les outils Microsoft.

Pour Commencer

Le shell est en préversion publique. Installez-le, configurez votre connexion Cosmos DB et activez le serveur MCP. De là, tout hôte d’agent compatible MCP peut découvrir et utiliser les outils.

Post original : Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

Windows App Dev CLI v0.3 : F5 depuis le terminal et UI Automation pour les agents

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

L’expérience F5 de Visual Studio est formidable. Mais devoir ouvrir VS uniquement pour lancer et déboguer une application Windows packagée, c’est trop — que ce soit dans un pipeline CI, un workflow automatisé, ou quand un agent IA effectue les tests.

Windows App Development CLI v0.3 vient d’être publié et répond directement à ce besoin avec deux fonctionnalités phares : winapp run et winapp ui.

winapp run : F5 depuis n’importe où

winapp run prend un dossier d’application non packagée et un manifeste, et fait tout ce que VS fait au lancement debug : enregistre un package loose, lance l’application et préserve le LocalState entre les re-déploiements.

# Compiler l'app, puis la lancer comme app packagée
winapp run ./bin/Debug

Fonctionne pour WinUI, WPF, WinForms, Console, Avalonia et plus. Les modes sont conçus pour les développeurs et les workflows automatisés :

--detach : Lance et rend immédiatement le contrôle au terminal. Idéal pour CI/automation.
--unregister-on-exit : Nettoie le package enregistré à la fermeture de l’app.
--debug-output : Capture les messages OutputDebugString et les exceptions en temps réel.

Nouveau package NuGet : dotnet run pour les apps packagées

Pour les développeurs .NET, il y a un nouveau package NuGet : Microsoft.Windows.SDK.BuildTools.WinApp. Après installation, dotnet run gère tout l’inner loop : build, préparation du package loose-layout, enregistrement Windows et lancement — en une seule étape.

# Laisser winapp init tout configurer
winapp init
# Ou installer directement
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui : UI Automation depuis la ligne de commande

C’est la fonctionnalité qui ouvre les scénarios agentiques. winapp ui donne un accès UI Automation complet à toute application Windows en cours d’exécution — WPF, WinForms, Win32, Electron, WinUI3 — depuis le terminal.

Ce qu’on peut faire :

Lister toutes les fenêtres de niveau supérieur
Parcourir l’arborescence UI Automation complète d’une fenêtre
Rechercher des éléments par nom, type ou ID d’automatisation
Cliquer, invoquer et définir des valeurs
Prendre des captures d’écran
Attendre l’apparition d’éléments — idéal pour la synchronisation de tests

Combiner winapp ui avec winapp run donne un workflow complet build → lancement → vérification depuis le terminal. Un agent peut exécuter l’app, inspecter l’état de l’interface et valider le résultat.

Autres nouveautés

winapp unregister : Supprime un package sideloadé quand on a terminé.
winapp manifest add-alias : Ajoute un alias pour lancer l’app par nom depuis le terminal.
Complétion automatique : Un seul commande pour configurer la complétion PowerShell.

Installation

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

La CLI est en preview publique. Le dépôt GitHub contient la documentation complète et l’annonce originale tous les détails.

Arrêtez de surveiller votre terminal : le mode détaché d'Aspire change la donne

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

À chaque fois que vous lancez un AppHost Aspire, votre terminal disparaît. Verrouillé. Occupé jusqu’à ce que vous fassiez Ctrl+C. Besoin d’exécuter une commande rapide ? Ouvrez un autre onglet. Envie de vérifier les logs ? Encore un onglet. C’est une petite friction qui s’accumule vite.

Aspire 13.2 corrige ça. James Newton-King a détaillé tout ça, et honnêtement, c’est une de ces fonctionnalités qui change immédiatement votre façon de travailler.

Mode détaché : une commande, terminal récupéré

aspire start

C’est le raccourci pour aspire run --detach. Votre AppHost démarre en arrière-plan et vous récupérez votre terminal immédiatement. Pas d’onglets supplémentaires. Pas de multiplexeur de terminal. Juste votre prompt, prêt à l’emploi.

Gérer ce qui tourne

Le truc, c’est que tourner en arrière-plan n’est utile que si on peut gérer ce qui s’y passe. Aspire 13.2 fournit un ensemble complet de commandes CLI pour exactement ça :

# 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

Ça transforme le CLI d’Aspire en un véritable gestionnaire de processus. Vous pouvez démarrer plusieurs AppHosts, vérifier leur statut, suivre leurs logs et les arrêter — le tout depuis une seule session de terminal.

Combinez-le avec le mode isolé

Le mode détaché se marie naturellement avec le mode isolé. Vous voulez lancer deux instances du même projet en arrière-plan sans conflits de ports ?

aspire start --isolated
aspire start --isolated

Chacune obtient des ports aléatoires, des secrets séparés et son propre cycle de vie. Utilisez aspire ps pour voir les deux, aspire stop pour arrêter celle dont vous n’avez plus besoin.

Pourquoi c’est énorme pour les agents de code

C’est là que ça devient vraiment intéressant. Un agent de code travaillant dans votre terminal peut maintenant :

Démarrer l’app avec aspire start
Interroger son état avec aspire describe
Vérifier les logs avec aspire logs pour diagnostiquer les problèmes
L’arrêter avec aspire stop quand il a terminé

Tout ça sans perdre la session de terminal. Avant le mode détaché, un agent qui lançait votre AppHost se retrouvait bloqué dans son propre terminal. Maintenant il peut démarrer, observer, itérer et nettoyer — exactement comme on voudrait qu’un agent autonome fonctionne.

L’équipe Aspire a misé là-dessus. Lancer aspire agent init met en place un fichier de compétences Aspire qui enseigne ces commandes aux agents. Ainsi, des outils comme l’agent de code de Copilot peuvent gérer vos workloads Aspire directement.

Pour conclure

Le mode détaché est une amélioration du workflow déguisée en simple flag. Vous arrêtez de jongler entre les terminaux, les agents ne se bloquent plus eux-mêmes, et les nouvelles commandes CLI vous donnent une vraie visibilité sur ce qui tourne. C’est pratique, c’est propre, et ça rend le cycle de développement quotidien nettement plus fluide.

Lisez le post complet pour tous les détails et récupérez Aspire 13.2 avec aspire update --self.

azd update — Une seule commande pour tous vos gestionnaires de paquets

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Vous connaissez ce message « Une nouvelle version de azd est disponible » qui apparaît toutes les quelques semaines ? Celui que vous ignorez parce que vous ne vous souvenez plus si vous avez installé azd via winget, Homebrew ou ce script curl que vous avez exécuté il y a six mois ? Eh bien, c’est enfin réglé.

Microsoft vient de publier azd update — une seule commande qui met à jour Azure Developer CLI vers la dernière version, quelle que soit la méthode d’installation d’origine. Windows, macOS, Linux — peu importe. Une seule commande.

Comment ça marche

azd update

C’est tout. Si vous voulez un accès anticipé aux nouvelles fonctionnalités, vous pouvez passer au build insiders quotidien :

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

La commande détecte votre méthode d’installation actuelle et utilise le mécanisme de mise à jour approprié en arrière-plan. Fini le « attends, j’ai utilisé winget ou choco sur cette machine ? »

Le petit bémol

azd update est disponible à partir de la version 1.23.x. Si vous êtes sur une version antérieure, vous devrez effectuer une dernière mise à jour manuelle en utilisant votre méthode d’installation d’origine. Après ça, azd update gère tout automatiquement.

Vérifiez votre version actuelle avec azd version. Si vous avez besoin d’une nouvelle installation, la documentation d’installation est là pour vous.

Pourquoi c’est important

C’est une petite amélioration de confort, mais pour ceux d’entre nous qui utilisent azd quotidiennement pour déployer des agents IA et des apps Aspire sur Azure, être à jour signifie moins de moments « ce bug était déjà corrigé dans la dernière version ». Une chose de moins à laquelle penser.

Lisez l’annonce complète et l’analyse approfondie de Jon Gallant pour plus de contexte.

.NET Aspire 13.2 Veut Devenir le Meilleur Ami de Votre Agent IA

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Tu connais ce moment où ton agent IA écrit du code solide, tu es tout excité, et puis tout s’effondre quand il essaie de lancer le truc ? Conflits de ports, processus fantômes, mauvaises variables d’environnement — soudain ton agent brûle des tokens à déboguer des problèmes de démarrage au lieu de construire des fonctionnalités.

L’équipe Aspire vient de publier un post très bien pensé sur exactement ce problème, et leur réponse est convaincante : Aspire 13.2 est conçu non seulement pour les humains, mais pour les agents IA.

Le problème est réel

Les agents IA sont incroyables pour écrire du code. Mais livrer une app full-stack fonctionnelle implique bien plus que générer des fichiers. Il faut démarrer les services dans le bon ordre, gérer les ports, configurer les variables d’environnement, connecter les bases de données et obtenir du feedback quand ça casse. Actuellement, la plupart des agents gèrent tout ça par essai-erreur — exécuter des commandes, lire les sorties d’erreur, réessayer.

On empile des instructions Markdown, des skills personnalisés et des prompts pour les guider, mais c’est imprévisible, ça ne se compile pas, et ça coûte des tokens juste pour parser. L’équipe Aspire a mis le doigt sur l’insight clé : les agents ont besoin de compilateurs et d’APIs structurées, pas de plus de Markdown.

Aspire comme infrastructure pour agents

Voici ce qu’Aspire 13.2 apporte à la table du développement agentique :

Toute ta stack en code typé. L’AppHost définit ta topologie complète — API, frontend, base de données, cache — en TypeScript ou C# compilable :

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();

Un agent peut lire ça pour comprendre la topologie de l’app, ajouter des ressources, câbler les connexions et compiler pour vérifier. Le compilateur lui dit immédiatement si quelque chose ne va pas. Pas de devinettes, pas d’essai-erreur avec les fichiers de config.

Une seule commande pour les gouverner toutes. Au lieu que les agents jonglent entre docker compose up, npm run dev et les scripts de démarrage de base de données, tout est simplement aspire start. Toutes les ressources se lancent dans le bon ordre, sur les bons ports, avec la bonne configuration. Les processus longs ne bloquent pas non plus l’agent — Aspire les gère.

Mode isolé pour les agents parallèles. Avec --isolated, chaque exécution d’Aspire obtient ses propres ports aléatoires et secrets utilisateur séparés. Plusieurs agents travaillent sur des git worktrees ? Ils n’entreront pas en collision. C’est énorme pour des outils comme les agents en arrière-plan de VS Code qui créent des environnements parallèles.

Des yeux d’agent grâce à la télémétrie. C’est là que ça devient vraiment puissant. La CLI Aspire expose des données OpenTelemetry complètes pendant le développement — traces, métriques, logs structurés. Ton agent ne se contente pas de lire la sortie console en espérant que tout va bien. Il peut tracer une requête échouée à travers les services, profiler les endpoints lents et identifier précisément où les choses cassent. C’est de l’observabilité de niveau production dans la boucle de développement.

L’analogie des bumpers de bowling

L’équipe Aspire utilise une super analogie : pense à Aspire comme les bumpers de piste de bowling pour les agents IA. Si l’agent n’est pas parfait (et il ne le sera pas), les bumpers l’empêchent de faire des gouttières. La définition de la stack empêche les mauvaises configurations, le compilateur attrape les erreurs, la CLI gère les processus, et la télémétrie fournit la boucle de feedback.

Combine ça avec quelque chose comme Playwright CLI, et ton agent peut réellement utiliser ton app — cliquer dans les flux, vérifier le DOM, voir les trucs cassés dans la télémétrie, corriger le code, redémarrer et retester. Construire, exécuter, observer, corriger. C’est la boucle de développement autonome que nous poursuivons.

Pour démarrer

Nouveau avec Aspire ? Installe la CLI depuis get.aspire.dev et suis le guide de démarrage.

Tu utilises déjà Aspire ? Lance aspire update --self pour obtenir la 13.2, puis pointe ton agent de coding favori vers ton repo. Tu seras surpris de voir jusqu’où il ira avec les garde-fous d’Aspire.

Pour conclure

Aspire 13.2 n’est plus seulement un framework d’applications distribuées — il devient une infrastructure essentielle pour les agents. Des définitions de stack structurées, un démarrage en une commande, des exécutions parallèles isolées et de la télémétrie en temps réel donnent aux agents IA exactement ce dont ils ont besoin pour passer de l’écriture de code à la livraison d’apps.

Lis le post complet de l’équipe Aspire pour tous les détails et vidéos de démo.

Le Mode Isolé d'Aspire Résout le Cauchemar des Conflits de Ports pour le Développement Parallèle

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Si tu as déjà essayé d’exécuter deux instances du même projet en même temps, tu connais la douleur. Le port 8080 est déjà utilisé. Le port 17370 est pris. Tuer quelque chose, redémarrer, jongler avec les variables d’environnement — c’est un tueur de productivité.

Ce problème empire, il ne s’améliore pas. Les agents IA créent des git worktrees pour travailler indépendamment. Les agents en arrière-plan démarrent des environnements séparés. Les développeurs font des checkout du même repo deux fois pour des branches de fonctionnalités. Chacun de ces scénarios frappe le même mur : deux instances de la même app qui se battent pour les mêmes ports.

Aspire 13.2 résout ça avec un seul flag. James Newton-King de l’équipe Aspire a écrit tous les détails, et c’est une de ces fonctionnalités « pourquoi on n’avait pas ça avant ? ».

La solution : `--isolated`

aspire run --isolated

C’est tout. Chaque exécution obtient :

Des ports aléatoires — plus de collisions entre instances
Des secrets utilisateur isolés — les chaînes de connexion et clés API restent séparées par instance

Pas de réattribution manuelle de ports. Pas de jonglage avec les variables d’environnement. Chaque exécution obtient un environnement propre et sans collision automatiquement.

Scénarios réels où ça brille

Checkouts multiples. Tu as une branche de fonctionnalité dans un répertoire et un bugfix dans un autre :

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

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

Les deux tournent sans conflit. Le dashboard montre ce qui tourne et où.

Agents en arrière-plan dans VS Code. Quand l’agent en arrière-plan de Copilot Chat crée un git worktree pour travailler sur ton code indépendamment, il peut avoir besoin d’exécuter ton AppHost Aspire. Sans --isolated, c’est un conflit de ports avec ton worktree principal. Avec, les deux instances fonctionnent tout simplement.

Le skill Aspire livré avec aspire agent init instruit automatiquement les agents d’utiliser --isolated quand ils travaillent dans des worktrees. Donc l’agent en arrière-plan de Copilot devrait gérer ça nativement.

Tests d’intégration en parallèle du développement. Besoin d’exécuter des tests contre un AppHost live tout en continuant à développer des fonctionnalités ? Le mode isolé donne à chaque contexte ses propres ports et sa propre config.

Comment ça fonctionne sous le capot

Quand tu passes --isolated, la CLI génère un ID d’instance unique pour l’exécution. Cela pilote deux comportements :

Randomisation des ports — au lieu de se lier à des ports prévisibles définis dans la config de ton AppHost, le mode isolé choisit des ports aléatoires disponibles pour tout — le dashboard, les endpoints de services, tout. Le service discovery s’ajuste automatiquement, pour que les services se trouvent mutuellement quel que soit le port attribué.
Isolation des secrets — chaque exécution isolée obtient son propre store de secrets utilisateur, indexé par l’ID d’instance. Les chaînes de connexion et clés API d’une exécution ne fuient pas dans une autre.

Ton code n’a besoin d’aucun changement. Le service discovery d’Aspire résout les endpoints au runtime, donc tout se connecte correctement quelle que soit l’attribution des ports.

Quand l’utiliser

Utilise --isolated quand tu exécutes plusieurs instances du même AppHost simultanément — que ce soit pour du développement parallèle, des tests automatisés, des agents IA ou des git worktrees. Pour du développement mono-instance où tu préfères des ports prévisibles, le aspire run classique fonctionne toujours très bien.

Pour conclure

Le mode isolé est une petite fonctionnalité qui résout un problème réel et de plus en plus courant. Alors que le développement assisté par IA nous pousse vers plus de workflows parallèles — agents multiples, worktrees multiples, contextes multiples — la capacité de simplement lancer une autre instance sans se battre pour les ports est essentielle.

Lis le post complet pour tous les détails techniques et essaie-le avec aspire update --self pour obtenir la 13.2.

Aspire 13.2 embarque une CLI de documentation — et votre agent IA peut l'utiliser aussi

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Vous connaissez ce moment où vous êtes plongé dans un Aspire AppHost, en train de câbler des intégrations, et vous devez vérifier exactement quels paramètres l’intégration Redis attend ? Vous faites alt-tab vers votre navigateur, vous cherchez sur aspire.dev, vous plissez les yeux sur les docs de l’API, puis vous revenez à votre éditeur. Contexte perdu. Flow brisé.

Aspire 13.2 vient de livrer une solution à ça. La CLI aspire docs vous permet de rechercher, parcourir et lire la documentation officielle d’Aspire directement depuis votre terminal. Et comme elle s’appuie sur des services réutilisables, les agents IA et les skills peuvent utiliser les mêmes commandes pour consulter la doc au lieu d’halluciner des APIs qui n’existent pas.

Le problème que ça résout vraiment

David Pine le dit parfaitement dans le post original : les agents IA étaient catastrophiques pour aider les développeurs à construire des apps Aspire. Ils recommandaient dotnet run au lieu de aspire run, référençaient learn.microsoft.com pour des docs qui se trouvent sur aspire.dev, suggéraient des packages NuGet obsolètes, et — mon préféré — hallucinaient des APIs inexistantes.

Pourquoi ? Parce qu’Aspire a été spécifique à .NET bien plus longtemps qu’il n’est polyglotte, et les LLMs travaillent avec des données d’entraînement qui précèdent les dernières fonctionnalités. Quand vous donnez à un agent IA la capacité de consulter les docs actuels, il arrête de deviner et commence à être utile.

Trois commandes, zéro onglet de navigateur

La CLI est d’une simplicité rafraîchissante :

Lister toute la documentation

aspire docs list

Retourne chaque page de documentation disponible sur aspire.dev. Besoin d’une sortie lisible par une machine ? Ajoutez --format Json.

Rechercher un sujet

aspire docs search "redis"

Recherche à la fois dans les titres et le contenu avec un score de pertinence pondéré. Le même moteur de recherche qui alimente les outils de documentation en interne. Vous obtenez des résultats classés avec titres, slugs et scores de pertinence.

Lire une page complète (ou juste une section)

aspire docs get redis-integration

Envoie la page complète en markdown dans votre terminal. Besoin d’une seule section ?

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

Précision chirurgicale. Pas besoin de scroller 500 lignes. Juste la partie dont vous avez besoin.

L’angle agent IA

C’est là que ça devient intéressant pour nous, développeurs qui construisons avec des outils IA. Les mêmes commandes aspire docs fonctionnent comme outils pour les agents IA — via des skills, des serveurs MCP, ou de simples wrappers CLI.

Au lieu que votre assistant IA invente des APIs Aspire basées sur des données d’entraînement obsolètes, il peut appeler aspire docs search "postgres", trouver les docs d’intégration officiels, lire la bonne page, et vous donner l’approche documentée. De la documentation en temps réel et à jour — pas ce que le modèle a mémorisé il y a six mois.

L’architecture derrière tout ça est intentionnelle. L’équipe Aspire a construit des services réutilisables (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) plutôt qu’une intégration ponctuelle. Cela signifie que le même moteur de recherche fonctionne pour les humains dans le terminal, les agents IA dans votre éditeur, et l’automatisation dans votre pipeline CI.

Scénarios concrets

Consultations rapides dans le terminal : Vous êtes trois fichiers en profondeur et vous avez besoin des paramètres de configuration Redis. Deux commandes, quatre-vingt-dix secondes, retour au travail :

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

Développement assisté par IA : Votre skill VS Code encapsule les commandes CLI. Vous demandez « Ajoute une base de données PostgreSQL à mon AppHost » et l’agent consulte les vrais docs avant de répondre. Pas d’hallucinations.

Validation CI/CD : Votre pipeline valide les configurations AppHost contre la documentation officielle de manière programmatique. La sortie --format Json se connecte proprement à jq et d’autres outils.

Bases de connaissances personnalisées : Vous construisez vos propres outils IA ? Envoyez la sortie JSON structurée directement dans votre base de connaissances :

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

Pas de web scraping. Pas de clés API. Les mêmes données structurées utilisées en interne par les outils de documentation.

La documentation est toujours à jour

C’est la partie que j’apprécie le plus. La CLI ne télécharge pas un snapshot — elle interroge aspire.dev avec un cache basé sur les ETags. Dès que la documentation est mise à jour, votre CLI et tout skill construit dessus le reflète. Pas de copies obsolètes, pas de moments « mais le wiki disait… ».

Pour conclure

aspire docs est une de ces petites fonctionnalités qui résout un vrai problème proprement. Les humains obtiennent un accès à la documentation natif au terminal. Les agents IA obtiennent un moyen d’arrêter de deviner et de commencer à référencer de vrais docs. Et tout est soutenu par la même source de vérité.

Si vous construisez avec .NET Aspire et n’avez pas encore essayé la CLI, lancez aspire docs search "votre-sujet-ici" et voyez comment ça se passe. Ensuite, envisagez d’intégrer ces commandes dans votre skill IA ou votre configuration d’automatisation — vos agents vous remercieront.

Consultez l’analyse approfondie de David Pine sur la construction des outils de documentation, et la référence officielle de la CLI pour tous les détails.

Cli | The .NET Blog

dotnet new WinUI : Créer des apps Windows sans toucher à Visual Studio

Démarrer en trois commandes

Ce qui est inclus

Pourquoi c’est important pour les développeurs qui n’utilisent pas Visual Studio

Cosmos DB Shell Est en Préversion Publique — Et Il a un Serveur MCP Intégré

Ce Qui le Différencie des Autres CLIs de Base de Données

La Base Open Source Compte

Trois Scénarios Qui Deviennent Plus Faciles

Pour Commencer

Windows App Dev CLI v0.3 : F5 depuis le terminal et UI Automation pour les agents

winapp run : F5 depuis n’importe où

Nouveau package NuGet : dotnet run pour les apps packagées

winapp ui : UI Automation depuis la ligne de commande

Autres nouveautés

Installation

Arrêtez de surveiller votre terminal : le mode détaché d'Aspire change la donne

Mode détaché : une commande, terminal récupéré

Gérer ce qui tourne

Combinez-le avec le mode isolé

Pourquoi c’est énorme pour les agents de code

Pour conclure

azd update — Une seule commande pour tous vos gestionnaires de paquets

Comment ça marche

Le petit bémol

Pourquoi c’est important

.NET Aspire 13.2 Veut Devenir le Meilleur Ami de Votre Agent IA

Le problème est réel

Aspire comme infrastructure pour agents

L’analogie des bumpers de bowling

Pour démarrer

Pour conclure

Le Mode Isolé d'Aspire Résout le Cauchemar des Conflits de Ports pour le Développement Parallèle

La solution : --isolated

Scénarios réels où ça brille

Comment ça fonctionne sous le capot

Quand l’utiliser

Pour conclure

Aspire 13.2 embarque une CLI de documentation — et votre agent IA peut l'utiliser aussi

Le problème que ça résout vraiment

Trois commandes, zéro onglet de navigateur

Lister toute la documentation

Rechercher un sujet

Lire une page complète (ou juste une section)

L’angle agent IA

Scénarios concrets

La documentation est toujours à jour

Pour conclure

La solution : `--isolated`