Our patches seem to work fine, yet none of the files on the disk are replaced.


Question


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.


Answer


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



  1. REINSTALL property

  2. REINSTALLMODE property

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


Question

I was wondering if there was any downside to specifying ALL, I assume this will also be the case with 3.0.

Answer

Not really, no.

Question

One 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)

Answer

Not 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






[Author: Robert Flaming]


This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

Comments (4)

  1. heaths says:

    The original thread stated that our patch building technology tracks which features are updated, actually. The last line of my summarized reply doesn’t make a lot of sense, and also conflicts with the next answer about drawbacks to setting REINSTALL=ALL.

    There is the chance that – depending on the REINSTALLMODE value – unpatched features will cause prompt for source issues because of changed files.

  2. Windows Installer Team says:

    Sorry for dropping that context Heath. Thanks for the correction.

    [Author: Robert Flaming]

    This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

  3. Robert Stegmann says:

    One thing I have noticed with patching under MSI30 is that if a patch adds a new component, then any features which use that new component, <i>regardless of if they were already installed or not</i>, are turned on by the patching process setting those features with ADDLOCAL. This does not seem like appropriate behavior to me. Any comments on that?