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?
Community Chosen Answer
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.