Our JRE MSI installer uses installer.dll to do most of the registration as well as copying files around to plugin dirs and the system dir. It also handles reregistration of older JRE's during uninstalling.

Consider the following PIP scenario:

1. User installs JRE 7u1
2. User runs the online installer for 7u2, a patch in place will take place, leaving the user with JRE 7u2 only
3. User then uninstalls 7u2.

During step 3, it will actually be running the installer.dll from 7u1. This is fine in most cases because the dll can work dynamically with any version. It does not have any versions hard-code inside it. It gets the version from the registry. The only time where this would be a problem is if we make uninstaller changes for the installer.dll in 7u2. During the PIP scenario, we would still be running the old 7u1 installer.

This issue is elusive because our dummy nextbld/nextver builds are built with the same codebase as the current version. So we would only catch this sort of issue when the dll changed in the NEXTVER/NEXTBLD, which never happens during normal testing.

We need to make sure the uninstaller runs the correct new version of the installer.dll