Applying transform to different MSI versions
I'm repackaging a product in the an msi, and the setup I have is that once I generate the msi, I create a transform(mst) for that msi that includes any configurations (extra files/registry entries) that need to be done on that product. Then, at install time, I just install the product like so: "msiexec /i [ProductMame].msi transforms=Configuration.mst".
That process seems to be working fine, however, I'm not sure how stable it is. The idea is to allow me to beable to apply that same configuration MST when I get a new version of the product. That is, when I get a new version of the product, I repackage it into an MSI, set its product code to what it had been before the update (This is necessary so that the mst can be applied), and then at install time, apply the same Configuration.mst.
Is this a reccommended method of applying configurations to products?
Answers (2)
General rule, NEVER use the same product code for 2 installers. This is a unique identifier for that specific msi, it is intended to be completely unique and should not be duplicated even if you are doing a small change. Especially if you are just starting packaging and do not understand how product codes are used. There are exceptions but they are pretty situational and you need to understand how product/upgrade codes work better before making those decisions.
You stated that you are repackaging a vendor install, to ME this means you are creating your own msi (via snapshot/monitor of exe) rather then just editing a vendor provided or extracted msi. So just be aware of how you are wording things and how we interpret your questions... Because it does make a difference in what you should/should not do with your edits. Repackaging an app removes most/all vendor support but gives you more freedom of editing, at the burden of more direct support of the installer.
MSTs are usually used to modify a vendor msi, if you are repackaging... then generally you are creating/building your own msi and any changes could be included naitively in the msi you built and thus not requiring an mst at all. Though there are good reasons to use mst to modify your custom msi (say if you have 2 different configurations of the same app). Just be aware mst is just a modification of an msi with out actually modifying the msi (you really don't want to edit vendor msi directly at all).
Here is a pretty good general article on product/package/upgrade codes. http://geekswithblogs.net/akraus1/archive/2011/07/02/146056.aspx
Rileyz touched on this, an MST is generally specific for an msi. Sometimes a mst can be used with different msi's but I would say you should consider that an exception rather then the rule. Looks like you have comprehension why an mst should not be considered "cross-installer" supportable:) Best practices would indicate an mst should be created for each seperate msi.
I would also personally add... I would not remove/delete components/features. You can condition them to not install in a number of ways but I would not remove them completely. I am not saying that it won't work; I personally don't because chances are; removal having a negative impact in the future is greater then just conditioning them to not install.
Comments:
-
To clarify, I'm repackaging the vendor installer using "snapshot method" into an MS, because the vendor doesn't provide an msi to begin with. The problem that I'm trying to solve with the MST, is to avoid having to spend time configuring a product over and over again for each subsequent version. So, I'm thinking to just apply all the custom configurations to a transform, and then apply that same transform to each subsequent product versions. - anonymous_94353 11 years ago
-
ah... understand. I would not advise using that method, it is really not the intended purpose of an MST. You certainly can try this and it would be easy enough to test (just build new msi/ism's from the IRP to get different product code packages quickly.
I don't know the labor involved in doing just the changes for your app, but usually when I resnap apps most of the work is the capture. Repeating changes is generally a very quick affair compared to actually capturing the install. If you document the process and use reg files to import registry settings the customization's at least for me are very quick.
If you really are set in not repeating the customization's after each new capture, I would look into building a Merge Module that include your changes. Merge Module are specifically designed to do what you want, rather then trying to shoe-horn MSTs into the same functionality.
When you are build your capture, just click the merge module (at least in InstallShield) you want to add and boom it is applied to your msi. - dandirk 11 years ago
Is this a vendor MSI?
I kinda see what your trying to doing. In Installshield you can create a MST with no validation, so it will work with other MSI's - use the transform wizard.
Open MSI. Tools > Create/Apply Transform. Follow your nose from there.
In regards to the ProductCode, if its a vendor package - I highly recommened you dont change it.
Comments:
-
Yes, this is a vendor MSI. Another problem that I think I may run into, is: What would happen if my MST removes some components from the vendor MSI? When I repackage a vendor product, components will get different GUID (I'm guessing), thus the MST would not be able to remove those same components. Does that make sense? - anonymous_94353 11 years ago
-
That will be something you will need to check each time. Thats why you have the job! :P
It all comes out in the testing.
Edit: thats pretty heavy duty editing if your removing components, can you do it by feature if its possible? If you do it means it can get migrated on update of never versions. - rileyz 11 years ago
