Understanding Windows Installer is like other Win32 Development
In a recent internal email thread, I'd offered this perspective to a person who could not find a simple answer to their question in either a) the documentation, b) the tools, or b) the community. Upon reflection, this advice can be applied frequently when one needs to delve deeply into Windows Installer. The specifics of the case at play here are not as interesting as the pattern which happens with the Windows Installer more than most would like.
This case is complicated
The matrix of scenarios and the behaviors from the Windows Installer for these scenarios are not written down in one place.
Further direct research would be wise
Generally, there is an expectation that a developer would compose a couple of small test packages, walk the scenarios, and assess whether the behaviors performed by the Windows Installer match the behavior requirements of the developer's team. This type of research is considered on par with other Win32 development.
Caveat: take care in picking the list of scenarios.
It is not uncommon for decisions to be made considering just one scenario (install) and then have other scenarios (uninstall, patching, multi-instancing, rollback, upgrade, versions/hashes, keypaths, etc) unexpectedly come up later in bugs and support calls. If you need to buy time for this work, sometimes it is useful to remind others that these decisions last the entire servicing lifetime of the product and can block one's ability to service which can have security connotations.
Comments
- Anonymous
October 07, 2008
Regarding the Win32 comparison, I typically compare Windows Installer to Win32 COM in terms of complexity and rules that must be followed but are nevertheless hard to actually find written down somewhere, and in learning curve too. There used to be a huge number of consultants, and companies providing COM training to explain it all. That mitigated the issues, but there has never been that level of 3rd party involvement in MSI technology.