Visual Studio | The .NET Blog

Mise à jour d'avril de Visual Studio 2026 : agent cloud, agents personnalisés et agent débogueur

Emiliano Montesdeoca — Thu, 14 May 2026 00:00:00 +0000

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

La mise à jour d’avril de Visual Studio 2026 (18.5) inclut l’intégration d’agent cloud, des agents personnalisés au niveau utilisateur, les outils C++ passant en GA, et un nouvel Agent Débogueur.

Agent cloud : déléguer le travail à une session Copilot distante

Depuis le sélecteur d’agents dans la fenêtre Chat, sélectionner Cloud permet de confier une tâche à un agent de codage Copilot distant. Vous décrivez le travail, l’agent crée un issue GitHub dans votre dépôt, puis ouvre une PR quand il a terminé. Vous recevez une notification avec “View PR” / “Open in browser” — tout fonctionne pendant que vous continuez à coder, ou même avec l’IDE fermé.

Les agents personnalisés vous accompagnent maintenant partout

Les agents personnalisés au niveau utilisateur stockés dans %USERPROFILE%/.github/agents/ ne sont plus limités à un dépôt — ils vous suivent d’un projet à l’autre. Le chemin de stockage est configurable sous Tools > Options > GitHub > Copilot > Chat. Le bouton + dans le sélecteur d’agents permet de créer directement de nouveaux agents. Ils obtiennent les mêmes capacités que les agents liés à un dépôt : conscience de l’espace de travail, outils, sélection de modèle et connexions MCP.

Agents intégrés : Agent, Ask, Copilot CLI, Debugger, Modernize, Profiler.

Les outils d’édition de code C++ passent en GA

Deux outils — get_symbol_call_hierarchy et get_symbol_class_hierarchy — sont maintenant activés par défaut. Ils donnent à Copilot une navigation consciente du langage dans les bases de code C++, couvrant les hiérarchies d’héritage et les chaînes d’appel de fonctions. Activez via l’icône Tools dans Copilot Chat. Fonctionne mieux avec les modèles d’appel d’outils.

Agent Débogueur : corrections validées contre le comportement réel à l’exécution

Démarrez depuis un issue GitHub ou Azure DevOps (ou une description en langage naturel), passez en mode Debugger, et l’agent :

Crée un reproducteur minimal
Génère des hypothèses de défaillance
Instrumente l’application avec des tracepoints et des breakpoints conditionnels
Lance une vraie session de débogage
Analyse la télémétrie en direct
Suggère un correctif précis

Vous restez dans la boucle tout au long du processus — c’est interactif, pas entièrement autonome.

Correction de priorité IntelliSense

VS supprime désormais les complétions Copilot pendant que la liste IntelliSense est active. Une seule suggestion à la fois. C’était un point de friction fréquent et c’est maintenant activé par défaut.

Notes de version complètes et téléchargement sur devblogs.microsoft.com.

Prise en charge du style SDK pour les projets d'extension dans Visual Studio

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

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

La prise en charge du style SDK pour les projets d’extension VSSDK est maintenant officielle dans Visual Studio 18.5 — les projets d’extension VSIX classiques peuvent abandonner l’ancien format .csproj style MPF.

Ce qui change dans le fichier de projet

Le changement le plus visible est la taille réduite du fichier de projet. Une extension VSSDK typique ressemble maintenant à ceci :

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net472</TargetFramework>
 <VSSDKBuildToolsAutoSetup>true</VSSDKBuildToolsAutoSetup>
 <VsixDeployOnDebug>true</VsixDeployOnDebug>
 <GeneratePkgDefFile>true</GeneratePkgDefFile>
 </PropertyGroup>
 <ItemGroup><ProjectCapability Include="CreateVsixContainer" /></ItemGroup>
 <ItemGroup>
 <PackageReference Include="Microsoft.VisualStudio.SDK" Version="17.14.40265" ExcludeAssets="runtime" />
 <PackageReference Include="Microsoft.VSSDK.BuildTools" Version="18.5.38461" />
 </ItemGroup>
</Project>

VSSDKBuildToolsAutoSetup=true applique des valeurs par défaut sensées : CreateVsixContainer=true et l’ancien DeployExtension=false. Cette unique propriété remplace une partie significative de ce qui devait auparavant être spécifié explicitement.

Améliorations du temps de compilation

Fast Up-To-Date Check et le support de la compilation incrémentale sont inclus. Pour les grandes solutions avec de petits changements, cela se traduit par une réduction du temps de compilation allant jusqu’à 75 % — significative si vous itérez sur une extension dans une grande solution hôte.

Nouveaux projets vs. existants

Les nouveaux projets d’extension créés en 18.5 utilisent automatiquement le style SDK. Les extensions de style MPF existantes continuent de fonctionner — la migration est optionnelle. Un point à surveiller lors de la migration : ajoutez <UseWpf>true</UseWpf> si votre extension utilise XAML. Vous devez également marquer l’extension comme déployable dans votre fichier .sln ou .slnx.

Le concepteur vsixmanifest est remplacé par l’éditeur XML par défaut — clic droit → Ouvrir avec si vous voulez l’ancien concepteur.

Chemin de migration agentique

L’agent Modernize dans vs-agent-plugins peut automatiser la migration. Plusieurs vraies extensions ont déjà été converties de cette façon : Smart Screen, Command Explorer, Postfix Templates et Whitespace Visualizer de Mads Kristensen.

À noter

VisualStudio.Extensibility (le framework d’extensibilité plus récent) prenait déjà en charge le style SDK. Cette mise à jour apporte la parité avec le chemin VSSDK classique. La seule exigence est la charge de travail de développement d’extensions Visual Studio.

Détails complets dans le post officiel.

Les outils Azure MCP sont désormais intégrés dans Visual Studio 2022 — Aucune extension nécessaire

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

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

Si vous avez utilisé les outils Azure MCP dans Visual Studio via l’extension séparée, vous connaissez la chanson — installer le VSIX, redémarrer, espérer que rien ne casse, gérer les incompatibilités de versions. Cette friction, c’est terminé.

Yun Jung Choi a annoncé que les outils Azure MCP sont désormais livrés directement avec la charge de travail développement Azure dans Visual Studio 2022. Pas d’extension. Pas de VSIX. Pas de danse du redémarrage.

Ce que ça signifie concrètement

À partir de Visual Studio 2022 version 17.14.30, le Azure MCP Server est inclus dans la charge de travail développement Azure. Si vous avez déjà cette charge de travail installée, il suffit de l’activer dans GitHub Copilot Chat et c’est parti.

Plus de 230 outils couvrant 45 services Azure — accessibles directement depuis la fenêtre de chat. Listez vos comptes de stockage, déployez une app ASP.NET Core, diagnostiquez des problèmes App Service, interrogez Log Analytics — le tout sans ouvrir un onglet de navigateur.

Pourquoi c’est plus important qu’il n’y paraît

Voici le truc avec l’outillage développeur : chaque étape supplémentaire est de la friction, et la friction tue l’adoption. Avoir MCP en tant qu’extension séparée signifiait des incompatibilités de versions, des échecs d’installation, et une chose de plus à maintenir à jour. L’intégrer dans la charge de travail signifie :

Un seul chemin de mise à jour via le Visual Studio Installer
Pas de décalage de version entre l’extension et l’IDE
Toujours à jour — le MCP Server se met à jour avec les releases régulières de VS

Pour les équipes qui standardisent sur Azure, c’est un vrai gain. Vous installez la charge de travail une fois, activez les outils, et ils sont disponibles à chaque session.

Ce que vous pouvez faire avec

Les outils couvrent l’intégralité du cycle de développement via Copilot Chat :

Apprendre — posez des questions sur les services Azure, les bonnes pratiques, les patterns d’architecture
Concevoir et développer — obtenez des recommandations de services, configurez le code de votre application
Déployer — provisionnez des ressources et déployez directement depuis l’IDE
Dépanner — interrogez les logs, vérifiez l’état des ressources, diagnostiquez les problèmes en production

Un exemple rapide — tapez ceci dans Copilot Chat :

List my storage accounts in my current subscription.

Copilot appelle les outils Azure MCP en coulisses, interroge vos abonnements, et renvoie une liste formatée avec les noms, emplacements et SKUs. Pas besoin du portail.

Comment l’activer

Mettez à jour vers Visual Studio 2022 17.14.30 ou supérieur
Assurez-vous que la charge de travail Azure development est installée
Ouvrez GitHub Copilot Chat
Cliquez sur le bouton Select tools (l’icône des deux clés)
Activez Azure MCP Server

C’est tout. Ça reste activé entre les sessions.

Un bémol

Les outils sont désactivés par défaut — vous devez les activer manuellement. Et les outils spécifiques à VS 2026 ne sont pas disponibles dans VS 2022. La disponibilité des outils dépend également des permissions de votre abonnement Azure, comme sur le portail.

La vue d’ensemble

Cela fait partie d’une tendance claire : MCP est en train de devenir le standard pour exposer les outils cloud dans les IDEs de développement. Nous avons déjà vu la release stable d’Azure MCP Server 2.0 et des intégrations MCP dans VS Code et d’autres éditeurs. L’intégrer dans le système de charges de travail de Visual Studio est la progression naturelle.

Pour nous développeurs .NET qui vivons dans Visual Studio, ça élimine encore une raison de basculer vers le portail Azure. Et honnêtement, moins on change d’onglet, mieux c’est.

Ce Paramètre de Fenêtres Flottantes de Visual Studio Que Vous Ne Connaissiez Pas (Mais Devriez)

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

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

Si vous utilisez plusieurs écrans avec Visual Studio (et honnêtement, qui ne le fait pas de nos jours ?), vous avez probablement vécu la frustration : les fenêtres d’outils flottantes disparaissent quand vous réduisez l’IDE principal, elles restent toujours au-dessus de tout le reste, et elles n’apparaissent pas comme des boutons séparés dans la barre des tâches. Ça fonctionne pour certains workflows, mais pour les configurations multi-écrans c’est frustrant.

Mads Kristensen de l’équipe Visual Studio a partagé un paramètre peu connu qui change complètement le comportement des fenêtres flottantes. Un menu déroulant. C’est tout.

Le paramètre

Tools > Options > Environment > Windows > Floating Windows

Le menu déroulant “These floating windows are owned by the main window” a trois options :

None — indépendance totale. Chaque fenêtre flottante a sa propre entrée dans la barre des tâches et se comporte comme une fenêtre Windows normale.
Tool Windows (par défaut) — les documents flottent librement, les fenêtres d’outils restent liées à l’IDE.
Documents and Tool Windows — comportement classique de Visual Studio, tout lié à la fenêtre principale.

Pourquoi “None” est le bon choix pour les configurations multi-écrans

Réglez-le sur None et soudain toutes vos fenêtres d’outils et documents flottants se comportent comme de vraies applications Windows. Elles apparaissent dans la barre des tâches, restent visibles quand vous réduisez la fenêtre principale de Visual Studio, et arrêtent de se forcer au premier plan.

Combinez ça avec PowerToys FancyZones et c’est un vrai changement. Créez des dispositions personnalisées sur vos écrans, placez votre Explorateur de Solutions dans une zone, le débogueur dans une autre, et les fichiers de code où vous voulez. Tout reste en place, tout est accessible indépendamment, et votre espace de travail paraît organisé au lieu de chaotique.

Recommandations rapides

Utilisateurs avancés multi-écrans : Réglez sur None, combinez avec FancyZones
Flotteurs occasionnels : Tool Windows (par défaut) est un bon compromis
Workflow traditionnel : Documents and Tool Windows garde tout classique

Astuce pro : Ctrl + double-clic sur la barre de titre de n’importe quelle fenêtre d’outils pour la rendre flottante ou l’ancrer instantanément. Pas besoin de redémarrer après avoir changé le paramètre.

Conclusion

C’est un de ces paramètres du type “je n’arrive pas à croire que je ne connaissais pas ça”. Si les fenêtres flottantes dans Visual Studio vous ont déjà agacé, allez changer ça tout de suite.

Lisez l’article complet pour les détails et les captures d’écran.

Bookmark Studio apporte la navigation par slots et le partage aux signets de Visual Studio

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

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

Les signets dans Visual Studio ont toujours été… corrects. Vous en placez un, vous naviguez au suivant, vous oubliez lequel est lequel. Ça fonctionne, mais ce n’a jamais été une fonctionnalité qu’on qualifierait de puissante.

Mads Kristensen vient de sortir Bookmark Studio, une extension expérimentale qui comble exactement les lacunes que vous avez probablement rencontrées.

Les signets peuvent être assignés aux slots 1–9 et accessibles directement avec Alt+Shift+1 à Alt+Shift+9. Les nouveaux signets obtiennent automatiquement le prochain slot disponible.

Le Gestionnaire de Signets

Une nouvelle fenêtre d’outils affiche tous vos signets avec filtrage par nom, fichier, emplacement, couleur ou slot.

Organisation avec labels, couleurs et dossiers

Les signets peuvent avoir des labels, couleurs et être groupés en dossiers. Toutes les métadonnées sont stockées par solution.

Exporter et partager

Bookmark Studio permet d’exporter les signets en texte brut, Markdown ou CSV.

Signets qui suivent le code

Bookmark Studio suit les signets relativement au texte auquel ils sont ancrés, ils ne dérivent donc pas vers les mauvaises lignes.

Pour conclure

Bookmark Studio ne réinvente rien. Il prend une fonctionnalité qui était « suffisante » depuis des années et la rend vraiment utile. Téléchargez-le depuis le Visual Studio Marketplace.

La mise à jour de mars de Visual Studio permet de créer des agents Copilot personnalisés — et find_symbol est révolutionnaire

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

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

Visual Studio vient de recevoir sa mise à jour Copilot la plus significative. Mark Downie a annoncé la version de mars, et le titre principal concerne les agents personnalisés — mais honnêtement, l’outil find_symbol pourrait être la fonctionnalité qui change le plus votre workflow.

Agents Copilot personnalisés dans votre repo

Envie que Copilot suive les standards de code de votre équipe ? Les agents personnalisés sont définis comme des fichiers .agent.md dans .github/agents/. Chaque agent a un accès complet au workspace, à la compréhension du code, aux outils, votre modèle préféré et aux connexions MCP.

Agent skills : packs d’instructions réutilisables

Les skills sont chargés automatiquement depuis .github/skills/ dans votre repo ou ~/.copilot/skills/ dans votre profil.

Le nouvel outil find_symbol donne au mode agent de Copilot une navigation de symboles basée sur les services de langage. Au lieu de chercher du texte, l’agent peut trouver toutes les références d’un symbole et accéder aux informations de type et de portée.

Pour les développeurs .NET, c’est une amélioration massive — les bases de code C# avec des hiérarchies de types profondes en bénéficient énormément.

Profiler des tests avec Copilot

Il y a un nouveau Profile with Copilot dans le menu contextuel du Test Explorer. Le Profiling Agent exécute le test et analyse automatiquement les performances.

Perf tips pendant le débogage en direct

L’optimisation des performances se fait maintenant pendant le débogage. Visual Studio affiche le temps d’exécution inline. Ligne lente ? Cliquez sur le Perf Tip et demandez à Copilot des suggestions.

Corriger les vulnérabilités NuGet depuis Solution Explorer

Un lien Fix with GitHub Copilot apparaît directement dans Solution Explorer quand une vulnérabilité est détectée.

Pour conclure

Les agents personnalisés et les skills font le titre, mais find_symbol est la pépite cachée — il change fondamentalement la précision de Copilot lors du refactoring de code .NET. Téléchargez Visual Studio 2026 Insiders pour tout essayer.

VS Code 1.112 : Ce qui devrait vraiment intéresser les développeurs .NET

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

VS Code 1.112 vient d’atterrir, et honnêtement ? Celui-ci frappe différemment si vous passez vos journées dans le monde .NET. Il y a beaucoup dans les notes de version officielles, mais laissez-moi vous épargner du défilement et me concentrer sur ce qui nous importe vraiment.

Copilot CLI est devenu bien plus utile

Le grand thème de cette version est l’autonomie de l’agent — donner à Copilot plus de liberté pour faire son travail sans que vous surveilliez chaque étape.

Direction et file d’attente de messages

Vous connaissez ce moment où Copilot CLI est à mi-chemin d’une tâche et vous réalisez que vous avez oublié de mentionner quelque chose ? Avant, vous deviez attendre. Maintenant vous pouvez envoyer des messages pendant qu’une requête est encore en cours — soit pour diriger la réponse actuelle, soit pour mettre en file d’attente des instructions de suivi.

C’est énorme pour ces tâches de scaffolding dotnet plus longues où vous regardez Copilot configurer un projet et pensez “oh attends, j’ai aussi besoin de MassTransit là-dedans.”

Niveaux de permissions

C’est celui qui m’excite le plus. Les sessions Copilot CLI supportent maintenant trois niveaux de permissions :

Permissions par défaut — le flux habituel où les outils demandent confirmation avant d’exécuter
Contourner les approbations — auto-approuve tout et réessaie en cas d’erreur
Autopilote — entièrement autonome : approuve les outils, répond à ses propres questions et continue jusqu’à ce que la tâche soit terminée

Si vous faites quelque chose comme créer une nouvelle API ASP.NET Core avec Entity Framework, des migrations et un setup Docker — le mode Autopilote signifie que vous décrivez ce que vous voulez et allez chercher un café. Il se débrouillera.

Vous pouvez activer l’Autopilote avec le paramètre chat.autopilot.enabled.

Prévisualiser les changements avant délégation

Quand vous déléguez une tâche à Copilot CLI, il crée un worktree. Avant, si vous aviez des changements non commités, vous deviez vérifier le Contrôle de Source pour voir ce qui serait affecté. Maintenant la vue Chat affiche les changements en attente juste là avant que vous décidiez de les copier, déplacer ou ignorer.

Petit détail, mais ça vous évite ce moment “attends, qu’est-ce que j’avais en staging ?”

Déboguez les apps web sans quitter VS Code

Le navigateur intégré supporte maintenant le débogage complet. Vous pouvez placer des breakpoints, parcourir le code pas à pas et inspecter les variables — le tout dans VS Code. Plus besoin de basculer vers Edge DevTools.

Il y a un nouveau type de débogage editor-browser, et si vous avez déjà des configurations de lancement msedge ou chrome, migrer est aussi simple que changer le champ type dans votre launch.json :

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Pour les développeurs Blazor, c’est un game changer. Vous exécutez déjà dotnet watch dans le terminal — maintenant votre débogage reste dans la même fenêtre aussi.

Le navigateur a aussi obtenu des niveaux de zoom indépendants (enfin), des menus contextuels avec clic droit appropriés, et le zoom est mémorisé par site web.

Sandboxing des serveurs MCP

Ceci importe plus que vous ne le pensez. Si vous utilisez des serveurs MCP — peut-être que vous en avez configuré un personnalisé pour vos ressources Azure ou vos requêtes de base de données — ils fonctionnaient avec les mêmes permissions que votre processus VS Code. Ça signifie un accès total à votre système de fichiers, réseau, tout.

Maintenant vous pouvez les sandboxer. Dans votre mcp.json :

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Quand un serveur sandboxé a besoin d’accéder à quelque chose qu’il n’a pas, VS Code vous demande d’accorder la permission. Bien mieux que l’approche “espérons que personne ne fait rien de bizarre”.

Note : Le sandboxing est disponible sur macOS et Linux pour l’instant. Le support Windows arrive — les scénarios distants comme WSL fonctionnent cependant.

Découverte des personnalisations en monorepo

Si vous travaillez dans un monorepo (et soyons honnêtes, beaucoup de solutions .NET d’entreprise finissent par en être un), ça résout un vrai point douloureux.

Avant, si vous ouvriez un sous-dossier de votre repo, VS Code ne trouvait pas votre copilot-instructions.md, AGENTS.md ou vos skills personnalisés situés à la racine du dépôt. Maintenant avec le paramètre chat.useCustomizationsInParentRepositories, il remonte jusqu’à la racine .git et découvre tout.

Ça signifie que votre équipe peut partager des instructions d’agent, des fichiers de prompt et des outils personnalisés entre tous les projets dans un monorepo sans que tout le monde ait à ouvrir le dossier racine.

/troubleshoot pour le débogage d’agents

Vous avez déjà configuré des instructions personnalisées ou des skills et vous vous êtes demandé pourquoi ils ne sont pas détectés ? Le nouveau skill /troubleshoot lit les logs de débogage de l’agent et vous dit ce qui s’est passé — quels outils ont été utilisés ou ignorés, pourquoi les instructions n’ont pas chargé, et ce qui cause des réponses lentes.

Activez-le avec :

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Puis tapez simplement /troubleshoot why is my custom skill not loading? dans le chat.

Vous pouvez aussi exporter et importer ces logs de débogage maintenant, ce qui est super pour les partager avec votre équipe quand quelque chose ne fonctionne pas comme prévu.

Support des fichiers image et binaires

Les agents peuvent maintenant lire les fichiers image depuis le disque et les fichiers binaires nativement. Les fichiers binaires sont présentés au format hexdump, et les sorties image (comme les captures d’écran du navigateur intégré) s’affichent dans une vue carrousel.

Pour les développeurs .NET, pensez : collez une capture d’écran d’un bug UI dans le chat et laissez l’agent comprendre ce qui ne va pas, ou faites-lui analyser la sortie du rendu d’un composant Blazor.

Références de symboles automatiques

Petite amélioration de qualité de vie : quand vous copiez un nom de symbole (une classe, méthode, etc.) et le collez dans le chat, VS Code le convertit maintenant automatiquement en une référence #sym:Name. Ça donne à l’agent le contexte complet sur ce symbole sans que vous ayez à l’ajouter manuellement.

Si vous voulez du texte brut à la place, utilisez Ctrl+Shift+V.

Les plugins peuvent maintenant être activés/désactivés

Avant, désactiver un serveur MCP ou un plugin signifiait le désinstaller. Maintenant vous pouvez les activer et désactiver — globalement et par workspace. Clic droit dans la vue Extensions ou la vue Personnalisations et c’est fait.

Les plugins de npm et pypi peuvent aussi se mettre à jour automatiquement maintenant, bien qu’ils demanderont une approbation d’abord puisque les mises à jour signifient exécuter du nouveau code sur votre machine.

Pour conclure

VS Code 1.112 pousse clairement fort sur l’expérience agent — plus d’autonomie, meilleur débogage, sécurité plus serrée. Pour les développeurs .NET, le débogage du navigateur intégré et les améliorations de Copilot CLI sont les fonctionnalités phares.

Si vous n’avez pas encore essayé de lancer une session Copilot CLI complète en mode Autopilote pour un projet .NET, cette version est un bon moment pour commencer. N’oubliez pas de configurer vos permissions et laissez mijoter.

Télécharger VS Code 1.112 ou mettre à jour depuis VS Code via Aide > Vérifier les mises à jour.

Visual Studio | The .NET Blog

Mise à jour d'avril de Visual Studio 2026 : agent cloud, agents personnalisés et agent débogueur

Agent cloud : déléguer le travail à une session Copilot distante

Les agents personnalisés vous accompagnent maintenant partout

Les outils d’édition de code C++ passent en GA

Agent Débogueur : corrections validées contre le comportement réel à l’exécution

Correction de priorité IntelliSense

Prise en charge du style SDK pour les projets d'extension dans Visual Studio

Ce qui change dans le fichier de projet

Améliorations du temps de compilation

Nouveaux projets vs. existants

Chemin de migration agentique

À noter

Les outils Azure MCP sont désormais intégrés dans Visual Studio 2022 — Aucune extension nécessaire

Ce que ça signifie concrètement

Pourquoi c’est plus important qu’il n’y paraît

Ce que vous pouvez faire avec

Comment l’activer

Un bémol

La vue d’ensemble

Ce Paramètre de Fenêtres Flottantes de Visual Studio Que Vous Ne Connaissiez Pas (Mais Devriez)

Le paramètre

Pourquoi “None” est le bon choix pour les configurations multi-écrans

Recommandations rapides

Conclusion

Bookmark Studio apporte la navigation par slots et le partage aux signets de Visual Studio

Navigation par slots

Le Gestionnaire de Signets

Organisation avec labels, couleurs et dossiers

Exporter et partager

Signets qui suivent le code

Pour conclure

La mise à jour de mars de Visual Studio permet de créer des agents Copilot personnalisés — et find_symbol est révolutionnaire

Agents Copilot personnalisés dans votre repo

Agent skills : packs d’instructions réutilisables

find_symbol : navigation consciente du langage

Profiler des tests avec Copilot

Perf tips pendant le débogage en direct

Corriger les vulnérabilités NuGet depuis Solution Explorer

Pour conclure

VS Code 1.112 : Ce qui devrait vraiment intéresser les développeurs .NET

Copilot CLI est devenu bien plus utile

Direction et file d’attente de messages

Niveaux de permissions

Prévisualiser les changements avant délégation

Déboguez les apps web sans quitter VS Code

Sandboxing des serveurs MCP

Découverte des personnalisations en monorepo

/troubleshoot pour le débogage d’agents

Support des fichiers image et binaires

Références de symboles automatiques

Les plugins peuvent maintenant être activés/désactivés

Pour conclure