I am working on packaging a third-party piece of software that has an Installshield installer wrapped around a .msi file. I run the Installshield setup.exe then go out to my %TEMP% folder to grab the msi. So far, so good.
The msi is about 35MB. I need to open it in WISE and add a new 1KB file to the install. I do this and I resave the .msi and now it is over 60MB! So I did another test. I opened the original msi file again and didn't make any changes, I just immediately selected the option to compile the msi. Again, over 60MB. What is WISE doing that just opening and resaving the msi would cause the file size to almost double?! Any ideas would be apprecated. Thanks!
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
I understand this is a vendor MSI. Why would you directly edit and compile the MSI when you can do that from a transform? That way your MSI size remain untouched and you prevent yourself from messing with the ever complicated nature of vendor authored MSI's. Since this MSI relies on a wrapper, you may need to modify the ISSETUPDRIVEN property to 1, IIRC..... check that out as well...
Answered 02/18/2010 by: PackageExpert
Blue Belt

Please log in to comment
0
Wise puts a lot of junk into MSI's just to let you know Wise has touched it.
Answered 02/19/2010 by: t_claydon
Senior Yellow Belt

Please log in to comment
0
Day two of your packaging course would have contained the maxim: Thou Shalt Not Directly Edit Vendor MSIs. A few minutes later, your facilitator (there are no longer "instructors", are there?) would have said: "When creating transforms with Wise, always set the MSIs read-only attribue on, because it has a habit of writing stuff in there anyway." Personally, I've never experienced that but a well-respected fellow member on the Symantec Connect forum says he has - many times - so I advise people accordingly.

For the record, Wise adds tables to MSIs for its own use, not simply to "let you know that Wise touched it." Tables like WiseSourcePath which contains paths to the package's original source files is one which springs immediately to mind.
Answered 02/19/2010 by: VBScab
Red Belt

Please log in to comment
0
For the record, Wise adds tables to MSIs for its own use, not simply to "let you know that Wise touched it." Tables like WiseSourcePath which contains paths to the package's original source files is one which springs immediately to mind.

Yeah exactly- Junk. [;)]
Answered 02/19/2010 by: t_claydon
Senior Yellow Belt

Please log in to comment
0
Different compression methods is my guess.
Answered 02/19/2010 by: Bobo
Orange Belt

Please log in to comment
0
as ian said wise puts all its junk when you compiled your msi

hopefully this time just open your msi in wise make your changes and save as mst

then go to the tools option and select msi diff

then you will be able to see for sure what has been added
Answered 02/19/2010 by: cygan
Fifth Degree Brown Belt

Please log in to comment
0
I know it isn't best practice to touch a vendor's msi, but there have been mutlitple times when I have done so for making minor file changes, and I have never had the file size increase so dramatically before.

I have to have a single msi for deployment reasons. I am using an mst for all the Property changes I need to make, including ISSETUPDRIVEN=1, and will use msitrans to merge the mst and vendor msi into one final msi before deployment. My problem though is that I need to add a couple of additional files to the msi. If I make those changes in the MST, it creates an additional cab file that would need to be deployed (and I need single msi file, no cabs). msitrans does not appear to merge the cab file into the original file. Is there a way to merge the mst's cab file into the msi's internal cab file?
Answered 02/19/2010 by: cyberbrad
Yellow Belt

Please log in to comment
0
I have to have a single msi for deployment reasonsWhat could they possible be? Any deployment system will be able to cope with specifying a transform, including Group Policy. If it's a "management dictat" thing, go and find the packager's baseball bat we talk about here so often and begin the "education" process.
Answered 02/19/2010 by: VBScab
Red Belt

Please log in to comment
0
If your company is so insistant about having a single file (ours is as well), you could always wrap the MSI and MST within a Wise-Script written package.
Answered 02/19/2010 by: icbrkr
Senior Yellow Belt

Please log in to comment
0
Check out this post. It is really handy for being able to add uncompressed files and have a single msi when completed.

http://itninja.com/question/how-to-add-non-requested-security-patch-to-mbsa-package-?6&mpage=1&key=adobe&#45789
Answered 02/19/2010 by: joedown
Second Degree Brown Belt

Please log in to comment
0
Thanks joedown! That looks like what I was needing. After using wimakcab.vbs on the AIP it created a new msi with my new files that was similar in size to the original vendor's file. Thanks to everyone else for the advice too. It was all helpful.
Answered 02/19/2010 by: cyberbrad
Yellow Belt

Please log in to comment
0
How will apply updates and/or patches to the vendor MSI now? You won't be able to, since you created a new one which the patch/upgrade won't recognise.

Oh...wait...it's OK. Vendors never patch or upgrade their products.
Answered 02/19/2010 by: VBScab
Red Belt

Please log in to comment
0
I just checked the Product Code of my new msi that had been msitrans'd and wimakcab.vbs'd and it is the same as the original msi (both have the same guids). Am I missing something?
Answered 02/19/2010 by: cyberbrad
Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity