Downgrading Shared Components

Downgrading Shared Components

  • Comments 3

Shared components define shared resources. It might seem obvious, but it’s important to understand that whatever you do to a shared resource during the installation of one product affects those same resources for any other product. For example, when upgrading one product to update files shared with another product, that other product will use the newer resources such as versioned files. It’s important to test those interactions before you ship to make sure the products can work with newer resources – that the changes to those resources are backward compatible.

By default, newer versioned files will overwrite older versioned files; however, non-versioned resources like text files or registry values are always overwritten. But even versioned files exhibit different behavior when and how they are downgraded.

Continuing with the example where one product is upgraded by another MSI and shares components with another product on the system, uninstalling either of those products leaves the files at the current version. Even if both products initially installed version 1.0 of a shared file and one of those products was upgraded to include version 1.1 of that same shared file, uninstalling that product which upgraded the file to 1.1 will leave the file version at 1.1. Shared components are ref-counted and when uninstalled that reference count is only decremented.

If one or even both of those products are patched by an MSP, uninstalling that patch will downgrade that file back to version 1.0 regardless of the reference count. But Windows Installer 4.5 introduced a new feature called shared component robustness will prevent shared components marked with this bit from being downgraded when a patch is uninstalled. Windows Installer 4.5 is available as a redistributable, and this feature is available in Windows Installer 5.0 included in Windows 7 and Windows Server 2008 R2.

But if you need this functionality down-level when you can’t take a dependency on Windows Installer 4.5, you need to consider whether you prefer that files are kept at their newest version or forcibly downgraded.

  • To keep files at their highest version without shared component robustness, major upgrades may be an appropriate option to consider.
  • To forcibly downgrade files regardless of their reference count, patches may be a more appropriate option.

The difference in behavior could be desirable for your scenarios, but if they are not you need to plan your product deployment strategy with Windows Installer accordingly.

Leave a Comment
  • Please add 6 and 8 and type the answer here:
  • Post
  • I've wrote a very similiar articel just a while ago, but in german:

    spablog.ontrex.ch/.../neue-komponenten-attribute-in-wise-package-studio-8-0

    maybe for german speaking people easier to understand.

  • "however, non-versioned resources like text files or registry values are always overwritten"  

    I would like to see a little clarification to that statement.  The behavior is more complex and needs to consider companion files versus keyfiles and file creation datetimes vs file modification datetimes.  The default file versioning rules don't simply overwrite non-versioned files all the time.

  • Windows Installer does not consider timestamps when deciding to update files. Timestamps are only used to determine whether the destination file was changed. By default, modified unversioned files are not overwritten (you can change this with "a" in REINSTALLMODE). Unfortunate as that may be.

    Companion files are based on their parent references' component actions - which should generally be versioned (since that's really the only way to get versioning). So what happens to the parent components should happen for the companion files. See msdn.microsoft.com/.../aa367997(VS.85).aspx.

Page 1 of 1 (3 items)