Repackaging a native MSI setup
I know the general advice is to NEVER repackage an MSI, but I occasionally encounter MSIs which make repackaging seem like the best option. These MSIs usually have custom actions which do not run silently (I usually repackage to enable silent deployment by AD) and cannot be removed.
I propose the following during repackaging...
1 - Perform a full install of the application (to ensure there will be no 'run from source' or 'install on first use' features)
2 - Instruct the installation to create normal shortcuts (rather than shortcuts to features)
3 - When I repackage, exclude all files & registry entries which relate to Windows Installer
4 - Accept the limitation that future upgrades/patches will not work directly as component codes will not match
Surely then there should be no problem with the new MSI package?
(Please don't post back saying it's against Microsoft best practise, or that the best advice is never to do it. But if you can see why this won't work, or if you've done it yourself I'd love to hear from you!)
I propose the following during repackaging...
1 - Perform a full install of the application (to ensure there will be no 'run from source' or 'install on first use' features)
2 - Instruct the installation to create normal shortcuts (rather than shortcuts to features)
3 - When I repackage, exclude all files & registry entries which relate to Windows Installer
4 - Accept the limitation that future upgrades/patches will not work directly as component codes will not match
Surely then there should be no problem with the new MSI package?
(Please don't post back saying it's against Microsoft best practise, or that the best advice is never to do it. But if you can see why this won't work, or if you've done it yourself I'd love to hear from you!)
0 Comments
[ + ] Show comments
Answers (3)
Please log in to answer
Posted by:
brenthunter2005
18 years ago
You have to be very careful when capturing vendors custom actions. You've got to think "what are they doing???".
At the end of the day, you are writing the captured files and registry keys to the computer. But what happens if these custom actions changes these files/registry keys depending on computer type etc.
I know what I'm trying to say, just can't say it
I understand your issue anyway. Its nasty when vendors who write MSI's don't write them to support all the functions of MSI's (admin points / administrative installs, silent execution, advertising etc)
At the end of the day, you are writing the captured files and registry keys to the computer. But what happens if these custom actions changes these files/registry keys depending on computer type etc.
I know what I'm trying to say, just can't say it
I understand your issue anyway. Its nasty when vendors who write MSI's don't write them to support all the functions of MSI's (admin points / administrative installs, silent execution, advertising etc)
Posted by:
rpfenninger
18 years ago
Of course it is very nasty to repackage a MSI [8D]
However, from my point of view I totally agree with you that it is sometimes the only way to get it to run in your environment. I already repackaged quite a few with success.
I think the most important thing in those cases is to test it thoroughly before deploying it to any productive environment.
However, from my point of view I totally agree with you that it is sometimes the only way to get it to run in your environment. I already repackaged quite a few with success.
I think the most important thing in those cases is to test it thoroughly before deploying it to any productive environment.
Posted by:
abritton
18 years ago
Good point Wildhair. I've actually just been on the Wise Repackaging course and will be moving to WPS6 very shortly.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.