Software Deployment

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...

Wise puts a lot of junk into MSI's just to let you know Wise has touched it.

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.

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. [;)]

Different compression methods is my guess.

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

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?

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.

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.

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

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.

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.

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?