I've been doing enterprise Windows development for 25 years. Last year I got fed up paying $2,000+/year for MSI tooling and decided to build my own. Here's what I learned about Windows Installer internals that nobody tells you upfront.

The MSI Format Is a COM-Structured Storage Database

An MSI file is literally a relational database — a Compound Document (OLE structured storage) containing around 30+ interrelated tables. Files, directories, registry entries, shortcuts, services — all defined as rows in tables with foreign key relationships. Get one relationship wrong and the installer silently fails or throws a cryptic error code.

The Windows Installer API lives in msi.dll and has no managed wrapper in .NET. You P/Invoke everything — MsiOpenDatabase, MsiCreateRecord, MsiRecordSetStream, MsiDatabaseCommit — around 40 different native calls. Error handling is fully manual; you get integer return codes and have to call MsiGetLastErrorRecord to get anything meaningful.

The Sequence Tables Are Brutal

Windows Installer has three separate sequence tables: InstallUISequence, InstallExecuteSequence, and AdminExecuteSequence. Each must contain specific standard actions in a precise numeric order. Miss one, put it in the wrong order, or include a non-standard action without a corresponding CustomAction table entry and you get error 2725 ("Invalid database tables") — with no indication of which action caused the problem.

I spent days tracing why installers built by InstallShield contained actions like setUserProfileNT and SetAllUsersProfileNT. Turns out those are InstallShield-specific custom actions, not standard Windows Installer actions. Every reference I found online listed them as "standard" — they're not. Adding them to your sequence table without the corresponding CustomAction entries will silently break your installer in enterprise environments.

ICE Validation Exists and Most Tools Ignore It

ICE (Internal Consistency Evaluators) are a set of validation rules built into the Windows SDK. ICE03, ICE27, ICE57, ICE80 — each checks a different aspect of MSI correctness. A lot of commercial tools ship MSIs that fail ICE validation but install anyway, because Windows Installer is lenient at runtime.

That leniency disappears in enterprise environments with strict Group Policy enforcement or when submitting to the Microsoft Store. Building ICE compliance in from the start — rather than retrofitting it — saves significant pain.

CAB Embedding Is Not Obvious

By default an MSI ships as two files — the .msi database and a separate .cab file containing the actual payload. To produce a single self-contained .msi you have to stream the CAB into the MSI's _Streams table using MsiRecordSetStream, and prefix the cabinet name in the Media table with #. The documentation for this is scattered across three different MSDN pages written in different decades, none of which reference each other.

The Directory Table Has Strict Rules

The Directory table defines the installation folder structure. It sounds simple until you realize:

What I Built

After working through all of this, I shipped InstallerStudio — a visual MSI designer built on WinUI 3 and .NET 10. No XML, no WiX dependency, no subscription. It handles files, Windows services, registry entries, shortcuts, file associations, custom actions, and a full installer UI with 14 dialogs including EULA, maintenance mode, and custom install directory browsing.

It ships its own installer, built with itself.

The hardest part of building it wasn't any single technical problem — it was the cumulative effect of underdocumented edge cases across a 20-year-old API that the industry has largely decided to abstract away rather than understand. I'm glad I went through it. The result is a tool with no external dependencies, no subscription, and no black box.

If you're building Windows software and want to create professional MSI installers without the overhead of WiX or the cost of InstallShield, try InstallerStudio free for 30 days.

Download Free Trial