Installer files - MSI split and modular regrouping considerations

Current Situation:

  1. We have 2 MSI files distributed and installed silently in the background through SCCM for all users as upgrades to monthly releases.
  2. The MSI compilation and SCCM distribution are handled by an external team for us once we provide them with the files (including chm, icons, pdf, images and other resource files along with the dlls) and the registry changes to be done during the install.

What we’re thinking to do:

  1. The 2 MSIs have become too big that we’re considering regrouping them in 5 separate installer files based on functionality and get them to the users according to their necessary access rights.
  2. We want to handle this internally in our own team and let that team handle only the SCCM part.

Newbie on Installer files:

We are unaware of anything related to the internals of an MSI file. Tried looking at InstEd and Orca to open an MSI file and it looks overwhelming for a newbie like me. We know which files need to be placed where in the Program Files folder and the registry settings during the install.

Questions:

  1. If we start afresh and create completely new installers without worrying about the GUIDs, will that work? (through some superficial searches on the internet, I read something like GUIDs of the components inside MSI will be tied to upgrades but I couldn’t clearly understand).
  2. If the answer to the above question is yes, is it possible to move to self-extracting EXE installers using Inno Setup? (Even if not, we can invest on learning WIX but just asking this question to see if we can reduce the investment with the learning curve that comes with MSIs).

1 answer

  • answered 2018-02-17 11:15 Matt

    1. This really depends on how you want to handle future upgrades. It is completely possible to ignore the GUIDS (in particular the Upgrade Code - which is used to identify products in the same family) as long as you manage the uninstall of all previous versions first. Alternatively, building an MSI with the same upgrade code but a newer version number will allow the Windows Installer to handle this automatically.

    2. If you're new to the internal workings of MSI's, then learning WIX from scratch can be quite an undertaking. You can pay for an InstallShield licence, which does make the process easier, but that doesn't come cheap. If you're used to deploying MSI's, I'd avoid switching to Inno or similar technologies at this point as they too have a learning overhead which would lead you away from your already established processes. At the end of the day, this is up to you however.

    Over all, my advice would be that if you're not extremely confident with the internal workings of an MSI, don't change anything in Orca or its like. That will only lead to problems further down the road.

    If your installation is simply the deployment of files and registry keys (no services, DLL registration, or other "advanced" install features), then go with whatever technology has the simplest learning curve for you.