Dueling MSIs
. I have a situation where I have to get a Crystal Reports service pack to install silently. The service pack is an installshield, non-msi installer.
The Crystal Reports 8.5 install itself is a vendor-supplied MSI, which they are installing silently as-is.
I’ve tried to create a transform to apply to the MSI, which includes a capture of the changes from the service pack, but that scenario does not seem to work at all. I was thinking about using a Wise capture of the service pack, and creating a separate MSI to lay on top of the vendor MSI.
My associate here brought up the problem of what happens in the situation of a repair? It would seem that either one or both of the MSI files would attempt to repair the missing files, and potentially, the original MSI file could overwrite a newer file with an older one.
Do you know what happens when two MSI files have ownership of the same file, and a repair is initiated?
This also brings up the point of why Crystal Reports starts with an MSI, but uses a straight-up Installshield for the service pack. You would think that a repair could potentially undo some of the changes of the service pack, right?
What do you think?
The Crystal Reports 8.5 install itself is a vendor-supplied MSI, which they are installing silently as-is.
I’ve tried to create a transform to apply to the MSI, which includes a capture of the changes from the service pack, but that scenario does not seem to work at all. I was thinking about using a Wise capture of the service pack, and creating a separate MSI to lay on top of the vendor MSI.
My associate here brought up the problem of what happens in the situation of a repair? It would seem that either one or both of the MSI files would attempt to repair the missing files, and potentially, the original MSI file could overwrite a newer file with an older one.
Do you know what happens when two MSI files have ownership of the same file, and a repair is initiated?
This also brings up the point of why Crystal Reports starts with an MSI, but uses a straight-up Installshield for the service pack. You would think that a repair could potentially undo some of the changes of the service pack, right?
What do you think?
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
aogilmor
19 years ago
I agree, they should have used MSI/MSP for service pack, especially for an MSI base install.
You can perhaps run the service pack silently from within the MSI, maybe in the Deferred execution section, or as a separate task in a batch file or script. I'd prefer that method to setup capture.
Better: if supported, run setup /a with the service pack. This will expand the files. Then, using a transform, add those files to the original installation MSI using the transform; then run
msiexec /i msiname.msi TRANSFORMS="transformname.mst"
You can perhaps run the service pack silently from within the MSI, maybe in the Deferred execution section, or as a separate task in a batch file or script. I'd prefer that method to setup capture.
Better: if supported, run setup /a with the service pack. This will expand the files. Then, using a transform, add those files to the original installation MSI using the transform; then run
msiexec /i msiname.msi TRANSFORMS="transformname.mst"
Posted by:
VikingLoki
19 years ago
Well, it's a bit of a questionable practice, but you can use the latest version of InstallShield to convert the non-msi installer into an msi. From there you have the building blocks to make an MSP to send to existing deployments or apply to an admin install point. Just download the InstallShield eval, use it to recompile the installshield non-msi installer into an msi. The installshield eval will inject a bunch of evaluation messages into the msi, but opening it in wise and recompiling will make all of them go away.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
