- Le développement natif sous Windows est complexe et inefficace à cause de la dépendance à l’installation de Visual Studio
- Des dizaines de Go à installer, une gestion opaque des composants et des problèmes d’incohérence de versions nuisent à la productivité des développeurs
- Pour résoudre cela, un outil CLI léger,
msvcup, a été développé afin de permettre l’installation automatique, isolée et par version de la toolchain MSVC et du Windows SDK
msvcup fournit un environnement de build reproductible grâce au parsing de manifestes JSON, à la configuration automatique de l’environnement (autoenv) et à la prise en charge des lock files- Cette approche permet un système de build entièrement automatisé et piloté par scripts sans dépendre du Visual Studio Installer
Les problèmes du développement natif sous Windows
- La méthode traditionnelle, qui impose d’installer Visual Studio, pèse sur les développeurs à cause d’un processus d’installation complexe et d’une gestion instable des dépendances
- Il faut sélectionner en détail la charge de travail “Desktop development with C++”, une version précise du SDK, etc., et un mauvais choix peut faire échouer le build
- L’installation peut atteindre 50 Go et, même après désinstallation, il reste des entrées de registre résiduelles et des services en arrière-plan
- Sous Linux, une seule commande du gestionnaire de paquets suffit pour installer une toolchain, alors que sous Windows il faut choisir manuellement des milliers de composants
- Visual Studio adopte une structure monolithique où éditeur, compilateur et SDK sont étroitement liés, ce qui complique la gestion des versions et la reproductibilité des environnements
- Résultat : les écarts du type « ça marche sur mon PC » sont fréquents, ce qui devient une barrière à l’entrée pour le développement natif
msvcup : une nouvelle approche
msvcup est un outil CLI open source qui télécharge et installe directement la toolchain MSVC et le Windows SDK sans installation de Visual Studio
- Chaque version est installée dans un répertoire isolé sous
C:\msvcup\, ce qui permet de faire cohabiter plusieurs versions sans conflit
- L’installation se termine en quelques minutes, avec inclusion automatique des outils de cross-compilation ARM
- La commande
msvcup install installe les paquets nécessaires, et la commande autoenv crée un répertoire d’environnement automatique
- Ce répertoire contient des exécutables wrapper qui définissent automatiquement les variables d’environnement ainsi qu’un fichier
toolchain.cmake, ce qui permet aussi de builder des projets CMake sans configuration supplémentaire
- Dans l’exemple de script
build.bat, msvcup permet de builder un programme “Hello, World” sans Visual Studio
- Il fonctionne sous Windows 10 ou version ultérieure avec seulement
curl et tar
Fonctionnement interne
- L’outil parse les manifestes JSON des composants Visual Studio distribués par Microsoft afin d’identifier uniquement les paquets nécessaires
- Les éléments essentiels — compilateur, linker, headers, bibliothèques, etc. — sont téléchargés directement depuis le CDN de Microsoft
- Les composants installés sont gérés via un lock file, ce qui permet à toute l’équipe de partager exactement les mêmes versions de paquets
- Les commandes
install et autoenv sont idempotentes et, si tout est déjà installé, elles se terminent en quelques millisecondes
Cas d’usage réel
- Tuple (application de pair programming) a intégré
msvcup à son système de build CI, supprimant ainsi la nécessité d’avoir Visual Studio préinstallé
- Il devient possible de builder des centaines de projets C/C++, y compris WebRTC, avec la même toolchain et le même SDK
- Les builds x86_64 et ARM sont tous deux pris en charge
- Avantages
- L’installation dans des répertoires par version permet une gestion parallèle des versions et une réinstallation facile
- Prise en charge automatique de la cross-compilation, sans configuration séparée
- Reproductibilité garantie via les lock files, avec détection immédiate des changements côté Microsoft
- Exécution rapide, sans réinstallations inutiles
Limites et extension
msvcup est conçu avant tout autour de la toolchain de compilation ; si l’IDE Visual Studio lui-même est nécessaire, l’installation officielle reste indispensable- Cependant, dans la plupart des workflows de développement natif, il fournit un environnement de build complet sans IDE
- Le script de build raylib donné en exemple installe automatiquement le SDK et la toolchain puis build le projet, sans Visual Studio
- Le processus de build est entièrement automatisé en ligne de commande, sans GUI
Conclusion
msvcup élimine la complexité du Visual Studio Installer et fournit un environnement de build natif léger et versionnable- Cette approche transforme le développement natif sous Windows en un modèle reproductible et automatisé, en aidant les développeurs à se libérer de la dépendance à l’IDE
- Repo : https://github.com/marler8997/msvcup
5 commentaires
Commentaires sur Hacker News
Ça a l’air plus compliqué que ce que je fais
Il suffit d’installer les LTSC Visual Studio Build Tools, puis de mettre une commande comme
cl yourprogram.c /link user32.lib advapi32.lib ...dans un fichier cmdJ’édite avec vim et j’ai construit pas mal d’utilitaires de cette façon
La toolchain Visual Studio a des versions LTSC et stables, mais la plupart des gens ne le savent pas
En environnement collaboratif, mieux vaut utiliser une version figée indiquée dans l’historique officiel des releases
Comme à l’époque où toute l’entreprise figeait la même version de toolchain
C’est pour ça que les étudiants et les développeurs amateurs ne le connaissent souvent pas
En revanche, ceux qui utilisent VS en entreprise le savent généralement
Quelqu’un sait quand elle sortira ?
Même les toolchains Linux ne sont pas à l’abri de l’enfer des dépendances
En installant un package npm, on se retrouve à avoir besoin de cmake, à gérer un conflit de version glibc, ou à tomber sur un projet C++ qui exige la dernière version de boost, etc.
Je me souviens encore des patchs openSSL à l’époque de heartbleed
Visual Studio est pénible aussi, mais le vrai enfer, c’est la confusion autour des versions de .NET Framework
Selon la version de Windows, les versions de .NET installées diffèrent, et on ne sait pas toujours clairement sur quel runtime l’app va s’exécuter
Du coup, pour des déploiements à grande échelle, il faut créer en C++ un shim de vérification de version .NET pour lancer le bon runtime
L’équipe glibc est extrêmement stricte sur la compatibilité ascendante et descendante
Cet article de LWN indique quand la compatibilité a été rompue pour la dernière fois
Le vrai problème, c’est quand les gens épinglent mal la version de glibc
Il ne faut pas faire de pinning sur glibc
GCC a bien cassé la compatibilité quelques fois, mais c’était surtout à cause de changements dans le standard C++
.NET Framework est déjà legacy, et depuis .NET 5 ces problèmes n’existent plus
Cela dit, beaucoup d’apps dépendent encore d’anciennes versions
Ça a résolu certains problèmes, mais ça a aussi créé une nouvelle complexité
Parfois, j’aimerais simplement revenir à l’époque du gestionnaire de paquets système
En embarqué, l’écosystème rust + probe-rs est bien plus agréable
L’installateur Visual Studio permet une installation unattended via des paramètres en ligne de commande
C’est expliqué dans la documentation officielle
En 2018, quand je travaillais sur un réseau satellite avec Internet lent, j’ai utilisé cette méthode parce qu’il fallait créer un package d’installation hors ligne
En regardant le script, on voit
curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/...comme ça
Mais je suis réticent à l’idée d’installer, sans vérification de hash, un exécutable provenant d’un compte GitHub d’origine inconnue
La situation sur Windows n’est pas aussi mauvaise que ce que dit le billet de blog, mais ça ressemble plus à un autre script d’installation risqué qu’à une vraie solution
Il suffit de lire et d’examiner le script soi-même
La méthode curl|sh consiste de toute façon à télécharger du code source ; ce n’est pas plus risqué que d’installer directement un exécutable
Son projet zigwin32 est même référencé dans le win32metadata de Microsoft
C’est donc quelqu’un de confiance
Cet article donne l’impression d’avoir été écrit par une IA
Des structures comme “it’s not just X, but Y” ou ces listes à emphase font très style LLM
Je me demande à quel point le projet a réellement été produit par un humain
La structure en liste paraissait maladroite et peu cohérente
Mais si c’est bien écrit par un LLM, c’est peut-être aussi la preuve que la qualité des LLM a beaucoup progressé ces derniers temps
Ça peut aussi venir d’un outil comme Grammarly
Parce que c’est plus confortable à lire pour le public
J’aimerais simplement qu’on indique franchement si de l’IA a été utilisée
msvcup est vraiment rafraîchissant comme tentative d’améliorer la DX de Visual Studio
J’aurais aimé avoir ça à l’époque de mes études
En alternative, on peut aussi installer Build Tools dans un conteneur
Il suffit de l’installer avec winget
winget install --id Microsoft.VisualStudio.2022.BuildToolsSi vous avez besoin des fonctionnalités WinRT :
winget install --id Microsoft.WindowsSDK.10.0.18362winget install --id Microsoft.WindowsAppRuntime.1.8Il faut aussi préciser quels workloads installer, et sans connaître le projet il y a beaucoup d’essais-erreurs
.vsconfigaide un peu, mais ce n’est pas parfaitJ’aimerais que les projets open source n’empêchent pas la prise en charge de MinGW
C’est un bon compilateur qui fonctionne bien sans DLL supplémentaires
Je ne comprends pas pourquoi l’open source forcerait un compilateur propriétaire
WIL est une bibliothèque souvent utilisée par les développeurs kernel, qui améliore fortement la sûreté du code et le confort de développement
Par exemple, le SDK Steamworks se compile avec MinGW mais plante au runtime
C’est dommage que ce billet de blog ne le mentionne même pas
La combinaison Clang + MSVC STL + WinSDK est bien plus propre
Ou alors on peut faire simplement comme ça
"winget install Microsoft.VisualStudio.BuildTools""winget install Microsoft.WindowsSDK.10.0.26100"Je préfère cette approche pour son rapport effort/stabilité
J’aimerais qu’il existe pour tous les langages un outil d’isolation de versions comme Python uv
On peut critiquer Bing, Copilot ou la pub, mais dans la plupart des cas, on peut les désactiver
J’ai eu le même problème en compilant aussi sur Ubuntu 24.04 puis en essayant d’exécuter sur CentOS 6 ou 7 : un problème de dépendance à glibc s’est produit.
Le fait que la version de glibc de l’environnement de compilation soit reprise par défaut semble être le problème.
On ne peut pas vraiment éviter une dépendance à
glibc..Contrairement aux langages de script comme Python/JV/.NET/JS, une dépendance à
glibcest inévitable.C’est aussi l’une des raisons pour lesquelles des bibliothèques sont distribuées pour chaque distribution.
Au minimum, si c’est compilé avec
glibc, cela peut tout à fait s’exécuter sur d’autres distributions de version supérieure s’il n’y a pas de dépendances particulières.Avec WSL2 et Ubuntu, Windows est effectivement devenu bien plus agréable pour développer. Mais si vous êtes dans un environnement Visual Studio plutôt que VS Code, ça semble au moins pouvoir aider un peu. Par contre, on dirait que ça ne fonctionne pas directement sous Windows avec un gestionnaire de paquets comme choco ou winget.
Les gestionnaires de paquets semblent en effet se concentrer davantage sur le résultat final que sur le SDK.
La plupart des développeurs configurent généralement des éléments comme
vcredistpour qu’ils soient installés dans le script du gestionnaire de paquets.Mais pour l’environnement de build, c’est un peu différent.