Master Packager Dev Overview

Master Packager Dev (MPDEV) is a command-line tool that lets developers build enterprise-quality Windows application packages – MSI and MSIX – from a single declarative JSON file.

The mission is simple: enable developers to ship installer packages that end-users love, enterprises want, and the Windows OS needs, without forcing the developer to learn years of Windows Installer package trivia first.

---

The problem Master Packager Dev solves

Application management on Windows has barely changed in the last 20 years. Every middle to large organization still spends significant time and money re-packaging vendor installers before they can be deployed at scale. The pattern is always the same:

1. An Independent Software Vendor (ISV) ships their app with an installer they figured out is the best for them – not for the organizations that will use it.
2. Organization IT discovers the package is missing per-machine support, silent install switches, configuration options, upgrade behaviour, or code signing.
3. IT teams (or third-party packagers) re-package the installer to make it deployable through their deployment systems like Configuration Manager, Intune, or similar.
4. Multiply that across thousands of vendors and hundreds of thousands of organizations and the cost runs into millions of avoidable rework.

The root cause is that ISVs and dev teams rarely understand the requirements of larger organizations, and there has been no toolchain that makes "doing it right" the easy path. Microsoft, owning these installer package technologies, has done a poor job educating and providing great tooling for developers to be able to build a great installer package for their apps. We want to finally solve this problem.

---

What Master Packager Dev does differently

MPDEV is built around a few simple principles:

• You describe what you want, MPDEV knows how to build it correctly. You write a single JSON file describing files, registry entries, shortcuts, services, signing, etc. MPDEV translates that into MSI tables or an MSIX manifest for you. The JSON reads and writes like a story that any developer and Large Language Model will be able to understand.
• One source, two outputs. The same JSON can produce both an .msi and an .msix in one build.
• No need to learn MSI/MSIX internals. Custom actions, components, features, KeyPath, MSIX capabilities, Package Support Framework, virtualization – MPDEV handles all that for you. You stay focused on what the installer should do and MPDEV builds it.
• Validation. We do not let you build whatever you want, but only what is right from our decade of experience. The build process shows warnings about MSIX limitations, security concerns, missing signatures, per-user vs per-machine pitfalls and other issues.
• Repeatable and CI-friendly. Because the package is a single text file, it diffs nicely in git and plugs straight into any build pipeline. Rebuild on every commit.

The result is that a developer can produce a professional, signed, upgradeable MSI/MSIX in minutes instead of days. Organizations using your installer package will save money on deployment, approval, and issue troubleshooting.

---

Who MPDEV is for

Audience	Why MPDEV helps
ISV / Application developers	Ship a clean, enterprise-deployable package on day one. Stop dropping ZIP files or unattended-install batch scripts on customers.
In-house dev teams	Build a single package per app that works for both per-machine deployment (MSI) and modern app-container scenarios (MSIX).
DevOps / Build engineers	Encode the entire installer as code. Diff it. Review it. Rebuild it on every CI run with one command.
IT / Application packagers	Use MPDEV to author a missing installer or to formalize an existing one without learning the full WiX/MSI/MSIX toolset.
Open source / Non-commercial maintainers	MPDEV is free for non-commercial and open-source use – ship a real Windows installer for your project without per-developer, per-machine fees.

---

MSI vs MSIX – quick primer

If you are new to Windows packaging, here is the 30-second version of what you are choosing between.

MSI – Windows Installer (.msi)

The classic installer format. Files are written directly to the file system, registry keys to the live registry, services are registered through the Service Control Manager, etc. Anything that has worked on Windows for the last 20 years works in MSI.

Use MSI when you need:

• Custom actions (run an EXE, DLL, PowerShell script, register a DLL, install a driver).
• Per-machine installs to Program Files.
• Windows services with custom accounts.
• Package dependency checks (e.g., "install .NET 8 first").
• An auto-updater service that polls a feed and silently installs new versions.
• Group Policy / Configuration Manager / Intune Win32 deployment.
• Maximum compatibility with older Windows versions.

MSIX – Modern App Package (.msix)

A signed, sandboxed package that installs into a private container. Files and registry writes are virtualized by the OS. Cleaner uninstall, automatic updates from a known location, and required for the Microsoft Store.

Use MSIX when you need:

• Microsoft Store distribution.
• App attach / Windows 365 / Cloud PC scenarios.
• A clean container with automatic rollback.
• App identity for modern Windows features (toast notifications, share targets, etc.).
• A required digital signature on every install.

Build both at once

MPDEV's killer feature is that a single JSON file can produce both formats simultaneously. You write the common configuration once, then add an msi: { … } section for MSI-only details and an msix: { … } section for MSIX-only details.

{
  "outputTypes": ["msi", "msix"]
}

---

Conventions used in the JSON

These conventions are universal in MPDEV and worth memorizing before you start.

Environment variable expansion

Any string in the JSON that matches a Windows environment variable like %PATH% or %ProgramFiles(x86)% is automatically expanded at build time. If the variable does not exist, it is replaced with an empty string.

To suppress expansion, double the percent signs: %%PATH%% is left literal.

You can also set custom env vars before running mpdev build and reference them in the JSON, which is great for CI / CD:

set MYVERSION=1.0.0
mpdev build package.json

"version": "%MYVERSION%"

Cross-property references

Any property in the JSON can reference another property's value with $.dotted.path:

"installDir": "%ProgramFiles(x86)%\\My Simple App",
"fileSystemEntries": [
  { "sourcePath": "build", "targetPath": "$.installDir" }
],
"outputFileName": "MyApp_$.platform_$.version"

Source paths vs target paths

• Source path – a path on your disk (where MPDEV reads from). Can be relative (resolved against the working directory or --working-dir) or absolute.
• Target path – the path inside the installed package (where the file ends up after install). Must be absolute.

MSI Formatted strings

In the MSI sections iniFiles, registries, and environmentVariables, strings enclosed in square brackets are resolved at install time to MSI properties. [INSTALLDIR] resolves to the install directory, [Manufacturer] to the publisher, etc. Unknown property names resolve to an empty string.

See Microsoft's MSI Formatted reference for the full grammar.