Software Deployment

My answer to this question has always been "it depends."

I am not a fan of repackaging (aka Setup Capture) because it essentially discards everything the vendor did to make the application install and puts you in charge of making sure that the application installs the way the vendor intended it to be. This means that if there are any special tasks that must be carried out (e.g. installing an Office or Acrobat add-in/plugin), you have to code the logic to handle this correctly. This gets even more complicated if you have to account for rollback activities. Sometimes, repackaging just doesn't work (see HP Solution Center example below). Therefore, I try to limit repackaging to simple applications. More complicated scenarios may be better handled by automating the vendor's installer by whatever means they support (silent response file, configuration file, command line parameters, etc.)

There are also cases where using the vendor's installer is just easier. If the vendor installer is very well built and makes the appropriate decisions during the installation, why not use it? On the flip side, I have encountered some crummy installers, so sometimes repackaging is a step up.

Another scenario I have encountered is an installer front-end to a bundle of MSIs. I enountered this with MS SQL Server 2005 Dev Client. It consisted of a custom setup.exe from Microsoft acting as a front-end to installing a bunch of supporting MSIs. Instead of creating separate packages for each MSI component, I just customized the Setup.ini to pass the appropriate parameters to Setup.exe to install what I wanted.

Here's another beastly example: HP Solution Center (for an HP Scanjet). I don't know what the software developers over at HP were smoking when they came up with this fiasco. This software bundle consists of a bunch of custom HP helper and front-end installation modules that wrap around a whole bunch of installation modules consisting of MSIs and other installation EXEs. I could find no easy way to directly install the MSIs because they required some combination of transforms, parameters, or support files. It was impossible to transform and Setup Capture was out of the question as it consistently resulted in a non-working pile of crap (as is sometimes the case with hardware). My only choice was to learn how HP constructed the installer and to customize its controlling INI file (autorun.inf) and then wrap the whole thing.

So sometimes wrapping is necessary. Sometimes repackaging works great, sometimes it gives you something not-so-great, and sometimes it doesn't work at all.

--Josh

Can you be more clear as to what you're trying to do? You're driving in two directions with that question.

i want to know that calling Setup.exe through custom action in msi is best practice or using repackager tool of admin studio is best way?

*bump*
Same question i posted some days ago.. :)

I'm curious about how many repackagers use silent commandlines through custom actions in an MSI.. To repackage a whole app when the silent install and uninstall run fine seems kinda.. pointless to me..
When someone has, for instance a software product which consists of several other software packages, and you need a notice/GUI to show/inform people that something is being installed/upgraded, it seems kinda pointless to me to repackage all small applications as a whole, or to package them one at a time. Especially when the packages install OK silently.

I have for instance an installation of a software product which consists of 60+ MSI's. Could run em all silently one after the other, but since it's an upgrade, the older version gets uninstalled first.. Ans since the older version is HUGE, it takes a while. People need to be informed something is being installed, ergo, one new MSI for the GUI and several custom actions to install the new software, one MSI after the other..

I don't really see the harm in it, just remember to look after the uninstall via another custom action as well. /me wondering how other repackagers about this..

Hi folks,
this works fine (done it myself quite a few times) .... But: Did you try to install such a thing on VISTA?
Most likely, you get problems with UAC, because this wrapped stuff does things, which triggers UAC.
If you do it with a second (and more) MSI, you have no chance to run it deferred, unless you use the built in Nesting.
With an exe-style setup, you can try to run it deferred, but this works not all the time.
For this kind of task, you can use WIWW. See: http://itninja.com/wiww
Regards, Nick

Re-packaging as an MSI should always be undertaken on anything unless it is an MSI when you receive it. If the package is an MSI when you receive it then you should create a transform that customizes and fixes any ICE errors in the applications install.

http://www.installshield.com/news/newsletter/0410-articles/why.asp

The link above is to an article on why to package as an MSI, however to bullet point.

1) Self healing of the application if a key file is corrupted
2) The ability to rollback a failed installation rather than leaving rubbish on the machine
3) Integration with a running Windows service to aid deployment

Just to point out that anyone can snapshot an installation and get a working MSI however its only the good people that can ICE fix that MSI and make use of the true benefits of the technology.

Something useful that also comes out of repackaging is understanding what DLL's and registry entries get deployed onto your build, this can aid troubleshooting in your environment!

Paul