\Building or Updating MSIsRepackaging - Converting an EXE to MSISetup Capture
Setup Capture is the most dangerous form of
repackaging and so in general should only be used
if you have not managed to get the "Wrap Existing Installers"
approach to work for the product.
The fact that most people do this first is "scarey" to say the least (WinInstall 2003 etc).
Generally the process taking a shapshot of the current state of a
computer, running an install and determining the differences.
This whole process is generally mostly automated with little control or
evaluation of the result.
This is typically done by people who have insufficient knowledge of Windows
(or parts of it) to determine where the dangers are.
The main dangers are:
- Setup capture is particularly dangerous for MSI based installers
(you won't find anyone recommending its use for these),
for this reason you should
create a transform
instead.
- You capture the end result and not the possibly very complex
decision making process that may have taken place to decide what
to install where.
It may have evaluated your hardware to decide what needed installation.
In other words it may fail on any other computer (or model of)
you try to install it on or just on some.
- The fact that an installer safely installed something does not
mean that you can safely repeat this on other boxes.
Setting of what needs to be "unique" names in registry are one
example of this problem
(for example I have seen SNMP registration issues because of this).
- Not all information gets captured due to the options being used.
- Not all information gets captured due due to your existing environment.
- Not all differences can be captured, for example if "part" of a
file or registry entry changes.
You would not want to clobber the IIS metabase because the installer
made a minor change to the configuration of IIS!
- You generally have to manually eliminate "expected"
or (what you believe to be) "non-relevant"
captured information .
- You must start with as virgin a machine as possible
(probably even down to not installing service packs).
This is a good reason for using virtual machines.
- Needs much more testing than the
"Wrap Existing Installers" approach.
You can't prove that it works, you can only prove that it can fail.
- Each capture of a new version of a product is completely new,
there is little learning from past mistakes, just because the
last version of your end product worked, doesn't mean this new one
will.
To mimimise the danger you must start on a "clean" system so
as not to miss the capture of critical information
(probably files or registry entries).
Although as implied above this can have its own issues.
You will probably also wish to test the generated MSI on multiple operating
systems and many configurations, probably the easiest way of doing this is
with virtual machines.
Where an installer is so crappy I can't
reliably wrap it, I generally
try to "recreate the setup", this is
basically a process of reverse engineering the installation process and
can involve setup/capture and all or some of the dangers above.
You generally put enough thought into it to eliminate the most likely issues.
For complex applications (or if you don't have the skills) you may wish
to use another installer tool to handle these requirements.
Links to Repackaging/Unattended Operation Resources |
Some external resources which may have specific information about the product you wish to repackage are: