Chained MSIs

[angusmf1]

I am having a problem using chained MSIs. I've installed msi 4.5 on a test box. In the non-streamed scenario, the chained msi is never run. I don't think it is a path issue. I've even tried using a hard path (c:\chained.msi) and nothing happens.

I've also tried streaming the chained MSI, but the build fails with eror 6151 "Cannot save target database." I've tried large and small MSIs, I've tried shortening the file name, etc. No dice.

Has anyone had success with these things? Aside from the headache of requiring msi 4.5, this would be a great solution for me.

In case anyone is curious, I'm trying to chain a postgreSQL install. Our product requires it. The old nested msi custom action works after a fashion, but leaves postges uninstallable if I don't remove it at the same time as I uninstall my product. I also can't easily do it as a pre or post operation because it requires user input that comes from my installer and I have to install databases against it after it gets installed. Other than going back to my Installscript project (incidentally, so many things have broken since IS 12, I can't upgrade my old projects) does anyone have a suggestion as to how I can install postgres in the middle of my install?

[Holger_G]

1) Have you performed a reboot after installing MSI 4.5?
2) InstallShield 2009 SP1 must be installed
3) create a verbose log file and check for IS_CHAINER_POST_COMMANDLINE
4) ResolveSource action must be in the execute sequence

[angusmf1]

1) Yes
2) got it
3) see below
4) it's there

Here is what I got for IS_CHAINER_POST_COMMANDLINE:

MSI (s) (44!FC) [09:00:13:911]: PROPERTY CHANGE: Adding IS_CHAINER_POST_COMMANDLINE property. Its value is '/l"c:\log.log" /qf /i"\"C:\Documents and Settings\Administrator\Desktop\postgresql-8.1-int.msi\"";"ADDLOCAL=server,psql,pgadmin,psqlodbc,binfiles INTERNALLAUNCH=1 DOSERVICE=1 DOINITDB=1 SERVICEDOMAIN=REGINAXP SERVICEACCOUNT=\"WSFTP_USER\" SERVICEPASSWORD=\"xxxx\" CREATESERVICEUSER=0 SERVICENAME=\"PostgreSQL Database Server 8.1\" SUPERUSER=\"xxxx\" SUPERPASSWORD=\"xxxx\" LOCALE=\"C\" ENCODING=\"UTF-8\" LISTENPORT=\"5432\" PERMITREMOTE=0 PL_PGSQL=1 PL_PERL=0 PL_PERLU=0 PL_TCLU=0 PL_PYTHONU=0 PL_JAVA=0 NOSHORTCUTS=1 BASEDIR=\"C:\Program Files\PostgreSQL\" DATADIR=\"C:\Ipswitch\PGData\""'.


The problem seems to be that there is no whitespace after the /i and /l switches. That kept me from being able to run this command line in a command window. Is this an IS bug?

[MichaelU]

The space you're expecting isn't required; this command line goes to our chainer executable, and not directly to msiexec. So long as your actual MSI is in place at C:\Documents and Settings\Administrator\Desktop\postgresql-8.1-int.msi on the machine running this install, that should work.

Are there any hints in the log file? You can either post the whole thing or go looking for the relevant section. This section will be after the initial execute sequence, and should look like a new execute sequence starting up, at least until it fails to find the .msi file.

How big is the entirety of the postgresql msi package, plus the current size of your package? There are some hard limits around 2gb, but assuming you're not hitting that, I'm not sure what 6151 would be without more info.

[angusmf1]

The PostgreSQL package exists in that location. When I copied the commandline from the log file and sent it to msiexec, it launched.

I don't see another execute sequence starting. I'm attaching the log file. I don't see anything that makes sense to me.

My package is about 20mb and the postgres package is another 20mb. I've tried a package as small as 130k, but it doesn't work. Is there any other info I can give you?

[MichaelU]

I don't see any sign of the actual chaining either. There are some early indications that it will indeed chain, but by the time it finishes the main execute sequence, it indicates a reboot is required and it exits. Can you try eliminating the reboot (stop setting REBOOT to Force), or perhaps by testing this in a sample outer project?

[angusmf1]

Removing the reboot allowed the chained MSI to run. That explains that. I guess this doesn't work the way I hoped it would. Is there a way to schedule any actions AFTER the chained msi runs, or would I have to chain another msi? I need to install some databases and start some services after postgres installs.

[MichaelU]

I don't have a good suggestion for this one. I would expect streamed locations to fail badly, as it appears the commit sequence is run before the reboot, and that will remove the files that will be used by the chained installations. Without seeing the logfile from after the reboot (which may require using the logging policy to generate), I'm not certain whether the ISChainPackagesPrepare action will even set up for the chaining. Even if it is called, the conditions are likely all incorrect.

Perhaps you could hack around this by moving the force reboot to a thin shell of an MSI which doesn't really install, and condition it in the chained packages view to run when you currently would set reboot to Force?

[angusmf1]

That is what I was thinking of doing. It may be a moot point in my case. Running the postgres install in a chain fails. It says it can't create a process to perform some task. Then it rolls back. Since I don't get this error when running standalone or nested, I assume it's a side-effect of the chaining.

[MichaelU]

Sorry to hear that. The one thing I know chaining effects is the order of when non-deferred execute sequence items after InstallFinalize, and deferred commit-execution actions will run. Outside of a transaction, all deferred actions (including commit) will run at InstallFinalize, followed by the rest of the immediate execute sequence. In a transaction, the immediate execute sequence will complete, and then the commit execution actions will run once the entire transaction completes.

This is a good thing to be aware of in general, as it can lead to problems when trying to use files in SUPPORTDIR in a commit execution action when the package is part of a transaction. It may be possible to address issues like this by transforming the custom actions to run at a different time or sequence. However moving custom actions between deferred and non-deferred may well prevent an action from working correctly anyway.

[MichaelU]

We've tracked down the cause of this -6151 error. If you change the name of a chained package with data files to something longer than nine characters, the data files' stream keys are too long to save in the MSI Database. Long term I'm not sure whether we'll be able to shorten the rest of the key, or just prevent longer package names. Either way, the best workaround now is to just shorten the length of all your chained packages' names.

[Christopher_Pai]

Similar problem:

http://community.installshield.com/showthread.php?p=421771#post421771