I am seeing a very strange issue with patches on msi 2.0, our patches seem to work fine, yet none of the files on the disk are replaced.
I tried regenerating the patches with the 2.0 toolset , but that did not help.
For MSI20 Patches, you will need to pass property REINSTALL=ALL.
You can omit REINSTALL=ALL with MSI30 and higher as it is smart enough to detect which features has changed.
More sophisticated patching users add a type 51 custom action to set the
- REINSTALL property
- REINSTALLMODE property
- Preselected property (to turn off the selection tree dialog)
before CostInitialize. Each of these was conditioned on the PATCH property. You could just set REINSTALL to ALL, but could cause resolve source issues for files you’re not even patching. These patching users keep track of the features their updating when they generate our patches then set the REINSTALL property to that comma-delimited list. That list is only the features they’re updating so that they don’t have the chance of resolve source issues for unpatched features.
QuestionI was wondering if there was any downside to specifying ALL, I assume this will also be the case with 3.0.
AnswerNot really, no.
QuestionOne final question, is there any problem using the 3.0 toolset to generate 2.0 compatible patches (assuming use any of 3.0 patching features such as patch sequencing)
AnswerNot really, no. Do make sure you set the schema to 200 (MSI 2.0) to support 2.0 patches, though. By default PatchWiz.dll 3.0+ will generate 3.0-style tables at least in the MSP, but the schema for existing tables hasn’t changed to the point of breaking 2.0 tables. Newer PatchWiz.dll to generate 2.0-style patches just fine.
Content credit also belongs to
- Ken, MSI Dev In Test, You can get other Ken insights about developing for Windows Installer from the Windows Installer Chat Archives
- Heath, DevDiv Dev, You can get other Heath insights about developing for Windows Installer from the Heath Stewart’s Blog