Posted: 08-June-2010 at 19:16 | IP Logged

It's amazing what we learn everyday, regardless of how much we think we know or how long we have been in the industry...

New tricks - sometimes, installed MSI packages (and not just) might report the wrong version. Common scenarios are with re-packaged MSI's, where the packager (through the repackaging software) decides, in his/her wisdom, to overwrite the built in DisplayVersion value with one of their choice (normally, the internal software control versions). For example, SQL 2005 will not install or even run setup successfully if the DoNet version is not at a particular level.

To get around this, I have carried out the following:
- using regedit/regedt32, have located the GUID of the product (these are normally well-know, public and unique)  - in this case, Microsoft .NET Framework 3.0 Service Pack 2 in the following registy key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion \Uninstall\{A3051CD0-2F64-3813-A88D-B8DCCDE8F8C7}
-in that key, the following value exists:DisplayVersion (type is RegSZ in this case), which SHOULD normally have a value of 3.2.30729, corresponding to the above mentioned product. If the value differs, many components dependent will fail.
- modified this value to ensure it reflects the correct installed version, and NOT the internal packaging version control (devised and used by the company's software packaging division) - easiest way is to check the version number of the installed binary for the product
- re-ran setup for the software I was attempting to install initially - SUCCESSFULY this time around.

This is a very annoying issue that can lead to significant lost productivity time, as one WASTES time and resources attempting WHY the software package doesn't install ALTHOUGH the correct version of the prerequisites exists in an intact state on the system