Packaging knowledge
MSI, EXE or DSM: where to start
Three source types, three routes into a package: what can be wrapped directly, what needs analysis and when migration is faster.
What the source type tells you
The source type does not decide the quality of the result, but the route to it. An MSI brings structure. An EXE brings arguments or none. A DSM package brings script logic somebody has to understand.
So the first question is not “how do I wrap this” but “what is actually here”.
MSI: the easy case
An MSI is a database with documented properties and return codes. The silent call is standardised, uninstall is built in. Effort usually comes from deciding which properties this product really needs, not from packaging.
For simple MSIs, the direct route without an extra shell is the better choice.
EXE: arguments and return codes
An EXE can be anything: a wrapper around an MSI, its own installer, a self-extracting archive. Silent parameters differ accordingly. What counts is vendor documentation and a test run with logging.
If the EXE only works with a UI, that is not a packaging problem but a case for repackaging or a vendor question.
DSM: legacy with structure
A DSM package contains a script.inc and a payload. The payload is often reusable; the script logic is not. It has to be read and distributed across the phases of a PSADT package.
Advantage: a description of the desired state already exists. Disadvantage: it is rarely complete, and unknown commands must stay visible as review items.
Decision table
| Source | Typical route | Effort | Risk | |---|---|---|---| | MSI with properties | direct Win32 package | low | low | | EXE with arguments | direct call or PSADT | medium | medium | | EXE without arguments | consider repackaging | high | high | | DSM | migrate to PSADT | medium to high | medium |
The table does not replace inspection, but it prevents treating a simple MSI like a special case.
---