Modifying existing installations using patches
We have a vendor supplied MSI that we need to make some changes to. We need to do stuff like add a few files, delete a couple registry values, that sort of thing.
Anyway I figure that's easy enough to do with the use of a transform. My concern is, in the future if the powers that be decide those files need to deleted, or additional files needed to added or other similar situations, how would I update existing installations? Obviously for new installation it's a straight forward process of modifying the original transform.
My concern is that if I don't update the existing installations proerply, a repair or heal of the installation may replace changes. Would I use an additional transform, or an msp?
I'm just trying to plan how future updates will be handled now so I can deploy the application in a way that supports us updating it easily.
Answers (4)
Generally an upgrade to the MSI is done with a newer version of the MSI. If you are creating some modifications of the package with your own files/registries MSP is the best option. Even if you repair, it will take care of the deleted or added files/registries.
Additional transform will not help because the application is already installed. Unless you write a script to uninstall the application first and then install the application with new MST.
Comments:
-
So just to clarify what you're saying the process for this deployment would be:
- Initially create an transform that contains our additional files/registry keys
- Deploy the installation with this transform
If in the future a change to these files are required, or we need to add additional keys, we would:
- Create an msp with these changes
- Deploy the msp to existing installations
- Modify the transform with these changes also so new installations receive them
And as you mentioned, the installations with the msp's deployed would retain these changes even if the installations is repaired/healed.
Just making sure I understand this process correctly. - bos302 12 years ago -
Correct... You have understood it correctly what I wanted to say. If your updates are very frequent then it is good what you have understood.
But if you will be updating it say once every year, then I would say don't create another MST at the time of update. Install the application as you would MSI + MST created. and then for update apply the patch (MSP) on top of it. so in 3 years you will just apply 3 MSP at the max or you can phase off the MSP as well if they are the same files. - piyushnasa 12 years ago
I would suggest that if you are modifying a vendor-supplied MSI you create an MST not an MSP. An MST is a transform for the original msi with your changes in it. An MSP is a patch, generally supplied by the vendor, to update their msi. If you need to alter your transform in the future then, as piyushnasa says uninstall and then re-install. If you create your own MSP to patch a vendor's msi you may find a vendor MSP supplied later will no longer work.
Comments:
-
Uninstalling and reinstalling the application everytime a change is required is not feasible because it's an ~2gb installation. The scope of our changes would only ever be modifying some default template file it uses or modifying some registry values. Surely an msp would be safe to deploy if it's not modifying anything significant? - bos302 12 years ago
Since you have now mentioned that your installation is ~2GB in size, I would say that MSP is the best option if you want to update just a few files.
>The scope of our changes would only ever be modifying
>some default template file it uses or modifying some
>registry values
In this scenario, I would typically create a stand-alone configuration MSI with its own ProductCode, versioning, etc. Call it 'VapourSoft_ACME_Tool_Customisation_V1.0.0.MSI' or similar.
This way, the vendor's MSI is untouched and the uninstall/new install of your customisations is relatively small.
