Repackaging multiple apps into a single msi

[mctozzy]

We're not quite sure whether what we're trying to do is possible, but basically we want to be able to repackage several apps into the one installer. Also, not every app actually has its own installer anyway...some are just "copy these files to where you want then".

Do you have any specific hints for this? It seems that the assumption is that you would be starting with an empty ai project each time you run the snapshotting wizard.

[Edited] Also, what is the process for dealing with packages that expect a reboot before installation is finalised? [For example to replace a system dll that is in use, but there would be other scenarios...]

Thanks.
MT

[GabrielBarbu]

Hello,

Indeed this is possible. Start up a "Repackage Installation" project.
On the "Customize Settings" page, click "Create new installation capture profile". On the settings tab, make sure the "Prompt and wait after installing the package" option is checked, then press OK.
The wizard will then start scanning the system and then start the selected installer. After finishing, a message box with the following prompt will pop up:

Are you ready to proceed ?

Press 'OK' when ready to continue the repackaging operation.

Do not press OK on this prompt. Install/copy all the apps that need repackaging on the system. Only after everything is copied/installed, press OK on the above dialog.

Also note that if you are trying to repackage .msi products, it would be more accurate if you import them rather than repackage them.

Regards,
Gabriel

[mctozzy]

OK Thanks for that, we sort of figured that was what you had to do.

We're also looking at using chained packages, as this is actually a more natural fit for our situation anyway, and may save us from having to repackage certain individual items which already have vendor msi's.

However, you didn't answer my question about reboots that an installer needs to complete the installation? How does the repackager work in this situation? (Years ago I used Norton Ghost's repackaging product which used the same snapshot comparison technique, and it had the feature to allow the reboot and then it proceeded with the snapshot comparison automatically when you restarted it.

Thanks,
MT

[GabrielBarbu]

Hello,

Indeed using chained packages is a more appropriate method. However note that chained packages requires Windows Installer 4.5 and will have no effect on systems which have Windows Installer 4.0 or earlier.

[Edited] Also, what is the process for dealing with packages that expect a reboot before installation is finalised? [For example to replace a system dll that is in use, but there would be other scenarios...]

The repackager will allow applications to initiate a system reboot, and it will automatically start at system startup to continue the capturing process. No interaction is necessary in this process.

Regards,
Gabriel

[mctozzy]

Excellent. Thanks for that. We have had more success using the chained packages approach, and so that looks to be how we will proceed.

Re Windows Installer 4.5, that's not a problem as this is intended for Windows 7 anyway. (I don't know if MS are releasing updates to Windows Installer services for earlier O/S to bring them up to the same level?)

Cheers,
MT

[mctozzy]

Not sure about the reboot thing...you said that if the application requires a reboot to complete installation, that AI will handle this and perform the poast snapshot after the reboot. But when we tried this, it doesn't seem to have any idea of a job that is 'in progress'...once you restart AI it has no memory of what was being done to that point? Are we missing something here?

Second question, as we are repackaging/combining (using chaining) a set of of different pieces software, some of which is 64 and some 32 bit, is it important that the 'master' project be set up as a mixed 32/64 project, or is this not critical? Was wondering how it copes with the question of the install directories in this case, and how they get passed through to the nested msi's.

The master project itself has nothing in it except the chained installers.

Otherwise, it's going quite well and we've been able to repackage a whole collection of dev tools and ended up with a 750MB msi! (Takes a while to build it mind you)

[GabrielBarbu]

Hello,

Not sure about the reboot thing...you said that if the application requires a reboot to complete installation, that AI will handle this and perform the poast snapshot after the reboot. But when we tried this, it doesn't seem to have any idea of a job that is 'in progress'...once you restart AI it has no memory of what was being done to that point? Are we missing something here?

Another user had this same issue. The solution is posted in the following thread:
http://www.advancedinstaller.com/forums ... f=2&t=5078

Second question, as we are repackaging/combining (using chaining) a set of of different pieces software, some of which is 64 and some 32 bit, is it important that the 'master' project be set up as a mixed 32/64 project, or is this not critical? Was wondering how it copes with the question of the install directories in this case, and how they get passed through to the nested msi's.

Please note that you should repackage 64bit components on a 64bit system and 32bit components on a 32bit system. You can then organize them into 64bit features and 32bit features and install them conditionally depending on the system's architecture.
Chaining mixed 64bit/32bit packages is not supported in Advanced Installer.

Regards,
Gabriel

[mctozzy]

Another user had this same issue. The solution is posted in the following thread:
viewtopic.php?f=2&t=5078

OK We'll have to try that again.

Please note that you should repackage 64bit components on a 64bit system and 32bit components on a 32bit system. You can then organize them into 64bit features and 32bit features and install them conditionally depending on the system's architecture.
Chaining mixed 64bit/32bit packages is not supported in Advanced Installer.

Ah, well it's not as simple as that. Many 32 bit packages are installed on Windows 7 x64. We don't see why we should have to repackage a 32bit app on a 32bit O/S if the intention is to only ever install in on a 64bit O/S?? Also, often when you have a "64 bit package", there are 32 bit components in it anyway.

Does this all just come down to what directory the software gets installed into? Does it matter if everything just gets installed to "Program Files" (rather than Program Files x86) whether it's 32 bit or 64 bit?

So far we don't seem to have struck any major problems in repackaging 32bit apps on Windows 7 x64 and then chaining them, other than the fact that they don't necessarily end up in the same "Program Files" folder that they would have if we had just run the original installer.

[GabrielBarbu]

Hello,

Ah, well it's not as simple as that. Many 32 bit packages are installed on Windows 7 x64. We don't see why we should have to repackage a 32bit app on a 32bit O/S if the intention is to only ever install in on a 64bit O/S?? Also, often when you have a "64 bit package", there are 32 bit components in it anyway.

In this case my suggestion from above is not necessary. However it is much safer to let an installer "think" it is installing on a 32bit system but actually installs on a 64bit, than let it think it is installing on a 64bit. This is because 64bit systems support 32bit apps, but the opposite is not true. But since your only intended platform is the 64bit, it does not really matter.

Does this all just come down to what directory the software gets installed into? Does it matter if everything just gets installed to "Program Files" (rather than Program Files x86) whether it's 32 bit or 64 bit?

It does matter. Some applications may not work properly if forced to install in Program Files even though they are 32-bit. This is because their requests would be redirected to "Program Files x86" even though they were not installed there.

Regards,
Gabriel