I had to build a Windows app (for scientists...) and while we do love to complain a lot about fragmentation and all the issues we have on Linux: Windows is a different kind of hell, with fragmentation just being at a different spot!
Creating CI for Windows was absolute hell, vcpkg is nice, but without caching slows down automation a lot, trying to build an MSI package was a very bad idea (what a crazy design from a Linux perspective!), getting anything reproducible isn't easy... 1/2
...so, therefore, huge shoutout to MSYS2 which was my salvation in so many ways! Automating Windows builds was really easy, and for the actual build steps I could even use a familiar UNIX-y environment, while still getting a fully native Windows binary out. Not sure why I didn't use this sooner for past projects!
Of course, the Linux builds of the same app were up and running in seconds, thanks to distro packages and great CI 😉 2/2
@matk interesting! this is, oddly enough, immediately relevant to me ... would you recommend avoid msi in 2026 even if the target audience is just "any windows user"? or is your recommendation to avoid msi only if you have a controlled downstream audience of scientists (or whoever) in an org environment?
i haven't had to think about windows builds or how to package them in over two decades, so i'd love to hear your war stories, if you're willing to go into the details a bit.
@deobald Yes, absolutely avoid MSI at all costs in 2026 *unless* you are targeting a corporate environment that specifically mandates it. Use NSIS, InnoSetup or one of the Windows package managers like Chocolatery instead. If your app can be sandboxed and work with Microsoft store restrictions, you can try MSIX too (although I didn't play with that).
MSI is *not* a package format like dpkg/rpm, and not a "copy this file there" installer, that's a mistake I made initially...
@deobald ...it instead is a structured database for installations, so instead of "copy this file now", MSI says "this file belongs to this component, which satisfies this feature" - and the engine then decides when and how to act.
Just renaming a file is hell unless you preplanned that, and MSI pushes a crazy amount of mental load onto the developer, instead of figuring things out by itself.
Without WiX it would be insanity, but even with it it's awful to use...
@deobald I would honestly argue that MSI features like its repair/self healing and its component model to share elements between "products" aren't even desirable in modern corporate environments.
If something breaks, you don't want to repair, you just reinstall/redeploy. Tons of state is bad. Most apps aren't exposing interfaces to others and bundle things, so no need for sharing. And it's too easy to break upgrades.
So, unless required, I wouldn't use MSI 😅
@matk what the actual hell. hahaha
i'm not sure i ever released anything but Baby's First MSI back in 2003 or whatever, so i've never stumbled across all this trash, even in my youth.
thank you for the warning!
@deobald It is kind of insane from a Linux engineer's perspective, especially in 2026. But MSI was created in 1999 for Windows, which doesn't have the strict(-ish) filesystem layout UNIX has, where software was shipped on CDs, computers were slower with expensive disk space, and in an environment where Microsoft had already invented the Windows Registry.
So I guess it made sense back then... I'm glad we didn't accidentally create something like this for Linux 😅
@deobald I bet the engineers who made the Windows Registry wished they had implemented some kind of ownership semantic into it, instead of making it a place to store random data from who-knows-where 😅
At least on Linux, apps were always restricted to only write into some locations (with $HOME being the wild-west of data littering, but not the entire filesystem at least :-P )
Matthias Klumpp
Steven Deobald