<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Vsix | The .NET Blog</title><link>https://thedotnetblog.com/nl/tags/vsix/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>nl</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Thu, 23 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/nl/tags/vsix/index.xml" rel="self" type="application/rss+xml"/><item><title>Visual Studio-extensieteams moeten stoppen met uitbrengen uit gewoonte en beginnen met uitbrengen via pipeline</title><link>https://thedotnetblog.com/nl/news/emiliano-montesdeoca/visual-studio-extension-ci-with-github-actions/</link><pubDate>Thu, 23 Jul 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/nl/news/emiliano-montesdeoca/visual-studio-extension-ci-with-github-actions/</guid><description>Een herbruikbare GitHub Actions-flow voor VSIX-versiebeheer en publiceren is nu eenvoudig genoeg dat handmatige releasestappen moeilijk te rechtvaardigen zijn.</description><content:encoded>&lt;p&gt;Originele bron: &lt;a href="https://devblogs.microsoft.com/visualstudio/automating-your-visual-studio-extension-builds-with-github-actions/"&gt;Automating your Visual Studio extension builds with GitHub Actions&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Als je Visual Studio-extensies onderhoudt en nog steeds aanzienlijke delen van de release handmatig uitvoert, is dit je signaal om te moderniseren.&lt;/p&gt;
&lt;p&gt;De workflow in dit bericht is bewust praktisch: versie stempelen, bouwen, testartefacten publiceren naar een galerij, en vervolgens stabiele bits publiceren naar Marketplace. Geen zware platformceremonie, alleen deterministisch releasegedrag.&lt;/p&gt;
&lt;p&gt;Wat ik het meest waardeer is dat versiebeheer wordt behandeld als pipelinestatus, niet als een pre-release checklist-item. Die ene beslissing elimineert een verrassend aantal fouten: niet-overeenkomende metadata, verouderde assembly-versies en inconsistente releasenotities.&lt;/p&gt;
&lt;p&gt;De splitsing tussen galerijpublicatie en Marketplace-publicatie is ook operationeel volwassen. Teams hebben een plek nodig voor snelle validatiebuilds die geen officiële-releasesemantiek dragen. Alles direct naar Marketplace pushen is hoogfrictie en moedigt risicovolle shortcuts aan.&lt;/p&gt;
&lt;p&gt;Een sterk releasepatroon voor extensieteams is:&lt;/p&gt;
&lt;p&gt;Bij pull requests en main-commits, produceer CI VSIX-artefacten en publiceer naar galerij voor testers.&lt;/p&gt;
&lt;p&gt;Bij getagde releases, publiceer ondertekende en gevalideerde pakketten naar Marketplace.&lt;/p&gt;
&lt;p&gt;Houd tokenbeheer minimaal met speciale geheimen en zo min mogelijk rechten.&lt;/p&gt;
&lt;p&gt;Mijn uitgesproken mening: extensie-ecosystemen lopen achter op app-ecosystemen in CI-discipline omdat kleine teams aannemen dat handmatige workflows beheersbaar zijn. Ze zijn beheersbaar tot ze dat niet meer zijn. Een gehaaste patch, een kapot pakket, een vergeten manifest-update, en het vertrouwen daalt.&lt;/p&gt;
&lt;p&gt;Deze herbruikbare acties zijn nuttig omdat ze herhaalde releaselogica eenmalig coderen en teams zich kunnen concentreren op extensiekwaliteit in plaats van verpakkingsmechanica.&lt;/p&gt;
&lt;p&gt;Er is nog steeds technisch inzicht nodig. Je moet Marketplace-publicatie afschermen achter kwaliteitscontroles, en je moet publicatiemanifesten behandelen als gecontroleerde release-artefacten. Maar de basispijplijncomplexiteit is nu laag genoeg dat handmatige releases meestal technische schuld zijn.&lt;/p&gt;
&lt;p&gt;Als je extensieontwikkeling leidt, standaardiseer dit dan nu in alle repositories. Je krijgt betere traceerbaarheid, eenvoudigere onboarding en minder eenpersoonsreleaseknelpunten.&lt;/p&gt;
&lt;p&gt;Voorgestelde uitrol:&lt;/p&gt;
&lt;p&gt;Begin met build plus galerijpublicatie voor één extensie.&lt;/p&gt;
&lt;p&gt;Introduceer versiestempeling na het valideren van je manifest-bronconventies.&lt;/p&gt;
&lt;p&gt;Voeg Marketplace-publicatie pas toe nadat geheimbeheer en releasepoorten zijn geïnstalleerd.&lt;/p&gt;
&lt;p&gt;Dit gaat niet over het najagen van DevOps-mode. Het gaat over betrouwbaarheid voor de mensen die je tooling installeren en verwachten dat updates werken.&lt;/p&gt;
&lt;p&gt;Stabiele extensie-ecosystemen worden op dezelfde manier gebouwd als stabiele applicaties: met saaie, herhaalbare automatisering die menselijk giswerk elimineert.&lt;/p&gt;</content:encoded></item></channel></rss>