Deployment Strategy Considerations

Many MSI challenges/problems are caused by the fact that developers are trying to force their setup to do something that it's not design to do - Configuration.

There is a fundamental design principle "Separation of concerns" applicable for all software development areas. It also should be applied to the deployment problem.

Setup (any setup) is concerned about deploying of the files. Full stop. Configuration is not part of the setup but a part of the application initialization stage. That is why MS introduced a great deployment guideline (as part of the Vista application certification). This guideline requires the applications to configure the user profile on the first start of the installed application but not at the installation. Break it and the product cannot be certified.

The benefits are enormous:
  • No need to have a complicated setup UI as no need to interact with the user after the last file is deployed. The user interaction is delegated to the application executable. You can still start the app (in config mode) at the last step of the installation.
  • Simple path for reconfiguration of the application. Start it at any time in the config mode without resorting to the "Repair", which effectively installs the product again for no real reason.
  • App upgrade is incredibly simple. Upgrade binaries and the app itself will pick the prev app settings if present.
  • Licencing, target system validation all becomes very straight forward.
  • ...

The deployment solution designed this way becomes something that I would call a "Lean Setup". The latest Wix# development effort is going towards this direction.

"Lean Setup" is not a requirement (unless you need a product certification) but a guide line only. But if this guideline is followed enormous amount of time and effort can be saved and the maintainability and UX of the product dramatically improved.

Last edited Sep 24, 2016 at 1:37 AM by oleg_s, version 1