Inside the MSI file format, again.

Far and away the most popular blog entry I have written to date is the entry where I discussed some of the inner details of the MSI file format.  I find this slightly amusing since there is so little actionable information in that blog entry.  I consider the blog entries about Windows Installer Components and the Component Rules far more useful to people working with setup.

[read more]

Comments (5)

  1. moo says:

    The problem with windows installers is if I have an application in C#, I have dependancies that I MUST install BEFORE this, like for example (just for now until its standard) the CLR, then I have drivers, then I have other COM components and software to install BEFORE my managed application (these use InstallShield 1.5 or whatever WYSE, NSIS doesnt matter what or at least it SHOULDNT MATTER) but this is IMPOSSIBLE.

    I want one MSI package. one install for EVERYTHING i bundle. But no, Microsoft dont let us do that so I have to reinvent the wheel for the umpteenth time and code up either a .bat file (or use WSH but thats not always installed) or a native C bootstrapper application. TIME WASTED, MONEY WASTED.

    Why should I use microsoft installer again?

    No reason to.

  2. Brad C. says:

    You should use Windows Installer because you are the one writing applications and not using/managing them. Your life *should* be difficult, because if you can save one administrator 10 minutes of install difficulty, think of how much aggregate time you will save IT admins around the world. The idea of .msi is a common, robust install experience. Don’t hack your way around it with a .bat file (ugh!).

    I haven’t looked into it, but isn’t the point of merge modules (.msm’s) to be able to include packaged components like the CLR? Does Microsoft provide such an .msm? If not, why not?

  3. moo says:

    Documentation is little to be desired.

    Hence I went for the quick solution that suits our needs, its not a consumer application install.

  4. moo says:

    Actually yeah sure but if its not easy to gain the knowledge on how to do this (if indeed it is possible) it may aswell NOT be possible to do and we shop with our money elsewhere.

    Our MSI is fine for our applicaiton, its the prerequisites that dont mix and match versions. This is the tool that Microsoft Ship with the IDE.

    Obviously this is a bad developer experience to use these tools in theyre current form.

  5. Naren S says:

    Totally agree with ‘moo’. Just like they invented the MSI file as a collection of installable ‘components’ with merge modules as shareable transport for components, they should have gone one step further and added an installer "Suite" layer on top that could be used to install serveral MSIs in a sequence.

    The corresponding installable entity at this level would be the ‘feature’ ofcourse. But that’s not very interesting for most people who don’t face this problem of upgradeable multi-MSI installers where we need to have the system manage features regardless of what MSI installed them.

    But yes a MSI level dependency management framework would be nice.