Productivity | The .NET Blog

Die Visual Studio Zwevende Vensters Instelling die Je Niet Kende (Maar Zou Moeten Kennen)

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

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

Als je meerdere monitoren gebruikt met Visual Studio (en eerlijk gezegd, wie doet dat tegenwoordig niet), heb je waarschijnlijk de ergernis ervaren: zwevende toolvensters verdwijnen als je de hoofd-IDE minimaliseert, ze blijven altijd bovenop alles staan, en ze verschijnen niet als aparte taakbalkknoppen. Het werkt voor sommige workflows, maar voor multi-monitoropstellingen is het frustrerend.

Mads Kristensen van het Visual Studio-team deelde een weinig bekende instelling die volledig verandert hoe zwevende vensters zich gedragen. Één dropdown. Dat is alles.

De instelling

Tools > Options > Environment > Windows > Floating Windows

De dropdown “These floating windows are owned by the main window” heeft drie opties:

None — volledige onafhankelijkheid. Elk zwevend venster krijgt zijn eigen taakbalkvermelding en gedraagt zich als een normaal Windows-venster.
Tool Windows (standaard) — documenten zweven vrij, toolvensters blijven gebonden aan de IDE.
Documents and Tool Windows — klassiek Visual Studio-gedrag, alles gebonden aan het hoofdvenster.

Waarom “None” de juiste keuze is voor multi-monitoropstellingen

Stel het in op None en plotseling gedragen al je zwevende toolvensters en documenten zich als echte Windows-applicaties. Ze verschijnen in de taakbalk, blijven zichtbaar als je het hoofd-Visual Studio-venster minimaliseert, en dringen zich niet meer naar voren.

Combineer dit met PowerToys FancyZones en het is een game changer. Maak aangepaste indelingen over je monitoren, snap je Solution Explorer naar één zone, debugger naar een andere, en codebestanden waar je wilt. Alles blijft op zijn plek, alles is onafhankelijk toegankelijk.

Snelle aanbevelingen

Multi-monitor power users: Stel in op None, combineer met FancyZones
Occasionele zwevende vensters: Tool Windows (standaard) is een solide middenweg
Traditionele workflow: Documents and Tool Windows houdt alles klassiek

Pro tip: Ctrl + dubbelklikken op de titelbalk van een toolvenster om het direct te laten zweven of te docken. Geen herstart nodig na het wijzigen van de instelling.

Afronding

Het is een van die “Ik kan niet geloven dat ik dit niet wist” instellingen. Als zwevende vensters in Visual Studio je ooit hebben geërgerd, ga dit nu wijzigen.

Lees het volledige bericht voor details en screenshots.

Azure DevOps Lost Eindelijk de Markdown Editor UX op Waar Iedereen Over Klaagde

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

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

Als je Azure Boards gebruikt, heb je dit waarschijnlijk meegemaakt: je leest door een werkitembeschrijving, misschien acceptatiecriteria bekijkend, en dan klik je per ongeluk dubbel. Boem — je bent in de bewerkingsmodus. Je wilde helemaal niets bewerken. Je was gewoon aan het lezen.

Dan Hellem kondigde de fix aan, en het is een van die veranderingen die klein klinkt maar echt wrijving verwijdert uit je dagelijkse workflow.

Wat er veranderd is

De Markdown-editor voor tekstuele werkitemvelden opent nu standaard in voorbeeldmodus. Je kunt inhoud lezen en ermee interageren — links volgen, opmaak bekijken — zonder je zorgen te maken dat je per ongeluk in de bewerkingsmodus terechtkomt.

Wanneer je daadwerkelijk wilt bewerken, klik je op het bewerkingspictogram bovenaan het veld. Wanneer je klaar bent, ga je expliciet terug naar de voorbeeldmodus.

Waarom het meer uitmaakt dan het klinkt

De community-feedbackthread hierover was lang. Het dubbelklik-om-te-bewerken-gedrag werd geïntroduceerd met de Markdown-editor in juli 2025, en de klachten begonnen bijna onmiddellijk.

Uitrolstatus

Dit wordt al uitgerold naar een subset van klanten en breidt zich de komende twee tot drie weken uit naar iedereen.

Bookmark Studio Brengt Op Slots Gebaseerde Navigatie en Delen naar Visual Studio-bladwijzers

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

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

Bladwijzers in Visual Studio zijn altijd… oké geweest. Je plaatst er een, navigeert naar de volgende, vergeet welke welke is.

Mads Kristensen heeft zojuist Bookmark Studio uitgebracht, een experimentele extensie die precies de gaten opvult die je waarschijnlijk bent tegengekomen als je bladwijzers regelmatig gebruikt.

Op slots gebaseerde navigatie

De kerntoevoeging: bladwijzers kunnen nu worden toegewezen aan slots 1–9 en direct worden bereikt met Alt+Shift+1 tot Alt+Shift+9. Dit verandert bladwijzers van “ik heb ergens bladwijzers” naar “Slot 3 is mijn API-controller, Slot 5 is de servicelaag.”

De Bladwijzerbeheerder

Een nieuw toolvenster toont al je bladwijzers op één plek met filtering op naam, bestand, locatie, kleur of slot.

Organisatie met labels, kleuren en mappen

Bladwijzers kunnen optioneel labels en kleuren hebben en in mappen worden gegroepeerd. Alle metadata wordt per oplossing opgeslagen.

Exporteren en delen

Bookmark Studio laat je bladwijzers exporteren als platte tekst, Markdown of CSV:

Bladwijzerpaden opnemen in pull request-beschrijvingen
Onderzoekssporen delen met teamleden

Haal het op van de Visual Studio Marketplace.

VS Code 1.112: Wat .NET-ontwikkelaars Eigenlijk Moeten Weten

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

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

VS Code 1.112 is net geland, en eerlijk? Dit treft als je je dagen in .NET-land doorbrengt. Er staat veel in de officiële releasenotes, maar laat me je wat scrollen besparen en focussen op wat er echt toe doet voor ons.

Copilot CLI is veel nuttiger geworden

Het grote thema van deze release is agentautonomie — Copilot meer ruimte geven om zijn werk te doen zonder dat je elke stap bewaakt.

Berichtsturen en wachtrij

Je kent dat moment waarop Copilot CLI midden in een taak zit en je realiseert dat je iets bent vergeten te vermelden? Eerder moest je wachten. Nu kun je berichten sturen terwijl een verzoek nog loopt — om de huidige respons bij te sturen of vervolgsinstructies in de wachtrij te zetten.

Machtigingsniveaus

Dit is waar ik het meest enthousiast over ben. Copilot CLI-sessies ondersteunen nu drie machtigingsniveaus:

Default Permissions — de normale stroom waarbij tools om bevestiging vragen voordat ze worden uitgevoerd
Bypass Approvals — keurt alles automatisch goed en probeert bij fouten opnieuw
Autopilot — volledig autonoom: keurt tools goed, beantwoordt zijn eigen vragen en gaat door totdat de taak klaar is

Je kunt Autopilot inschakelen met de instelling chat.autopilot.enabled.

Webapps debuggen zonder VS Code te verlaten

De geïntegreerde browser ondersteunt nu volledig debuggen. Je kunt breakpoints instellen, door code stappen en variabelen inspecteren — allemaal in VS Code.

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

Voor Blazor-ontwikkelaars is dit een game changer.

MCP-server sandboxing

Als je MCP-servers gebruikt, kun je ze nu sandboxen:

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

Monorepo-aanpassingen ontdekken

Als je in een monorepo werkt, loopt VS Code met de instelling chat.useCustomizationsInParentRepositories omhoog naar de .git-root en ontdekt alles.

/troubleshoot voor agentdebugging

Heb je ooit aangepaste instructies of vaardigheden ingesteld en je afgevraagd waarom ze niet worden opgepikt? Schakel de nieuwe /troubleshoot-vaardigheid in met:

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

Afsluiting

VS Code 1.112 pusht hard op de agentervaring — meer autonomie, betere debugging, strakker beveiliging. Download VS Code 1.112 of update vanuit VS Code via Help > Check for Updates.