I have a .msi that I want to install (chain) with another .msi.
I've created the new chained .msi package in Releases and selected the .msi through the Browse button (clicking yes to use streaming). I've tried both leaving Install Condition as "Not Installed" and changing it to "True".
I built the .msi, and ran the install, but it never installs the chained package. There is no mention of it anywhere during the installation. I know that it's included, since the resulting .msi file size is appropriate. It's just not installing.
Is there anything I'm missing? What else is required to install a chained .msi? (I have manually installed Windows Installer 4.5)
Are you installing any prerequisites that require a delayed reboot? Searching the log for chainer or chainpackage should find all the relevant entries, whether they're the provided actions, command line, Windows Installer scheduling of the embedded chainer, etc. Does the logging around ISChainPackagePrepare tell you anything?
OK, I managed to get it to work... temporarily. I now have a .exe and a .msi (streamed). Then I made some changes, and I'm not sure which one is causing the following problem:
During the installation, it jumps to the setup error screen, saying that the product was not installed. I think this is the relevant area of the log file: [code] MSI (s) (78:50) [13:16:56:734]: Doing action: ISChainPackagePrepare Action 13:16:56: ISChainPackagePrepare. Action start 13:16:56: ISChainPackagePrepare. MSI (s) (78:50) [13:16:56:765]: Creating MSIHANDLE (3) of type 790542 for thread 3408 MSI (s) (78:C4) [13:16:56:765]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI3FDC.tmp, Entrypoint: ISChainPackages MSI (s) (78:0C) [13:16:56:765]: Generating random cookie. MSI (s) (78:0C) [13:16:56:781]: Created Custom Action Server with PID 3040 (0xBE0). MSI (s) (78:54) [13:16:56:843]: Running as a service. MSI (s) (78:54) [13:16:56:859]: Hello, I'm your 32bit Impersonated custom action server. MSI (s) (78!BC) [13:16:56:968]: Creating MSIHANDLE (4) of type 790541 for thread 2748 MSI (s) (78!BC) [13:16:56:968]: Note: 1: 2205 2: 3: ISChainPackage MSI (s) (78!BC) [13:16:56:968]: Note: 1: 2228 2: 3: ISChainPackage 4: SELECT * FROM `ISChainPackage` ORDER BY `Order` MSI (s) (78!BC) [13:16:56:968]: Closing MSIHANDLE (4) of type 790541 for thread 2748 MSI (s) (78:C4) [13:16:56:968]: Closing MSIHANDLE (3) of type 790542 for thread 3408 Action ended 13:16:56: ISChainPackagePrepare. Return value 3. Action ended 13:16:56: INSTALL. Return value 3. [/code]
The 2205 note indicates the ISChainPackage table is missing; this results in the failure of the ISChainPackagePrepare action. I'm suprised that you would have this action without any entries in the table; have you used any release flags to exclude your chained packages?
OK, I ran the .exe and grabbed the extracted .msi from %temp%.
Using the tool mentioned here: http://www.testingreflections.com/node/view/5160 (I assume this tool is acceptable), the ISChainPackage table does not appear. However, the ISChainPackageData and MsiEmbeddedChainer tables are present.
OK, I ran the .exe and grabbed the extracted .msi from %temp%.
The ISChainPackage table does not show up in the tool mentioned here: http://www.testingreflections.com/node/view/5160 (I assume this tool is acceptable). However, the ISChainPackageData and MsiEmbeddedChainer tables are present.
Apparently this is happening because I left the Product Code blank.
I use the automation interface to build both packages, placing the correct .msi in place for the .exe build. Is there a way to determine the chained MSI's Product Code at build time? I am currently using sed to substitute it into the xml, but it's not pretty.
No; unfortunately at build time we do not necessarily know where the MSI is, so we cannot read it. (Consider the case where you say to find it on the DISK1 folder, but don't actually place it there until you create your CD layout.) As hacks go, sed sounds like an okay choice.
On the other hand, it really sounds like we should catch this case and throw a build warning/error - thanks for tracking down the root cause. I've logged this under IOA-000048942 so we can fix it in the future.
