Is it possible to access file and registry manifests and file checksums from MSI after installation? Or alternatively, is there a way to have msi verify an existing installation and generate a detailed log? I ask because I need to create an Install Qualification report that gets generated after installation or on demand. If I could read the manifests straight from msi for my product, then it would be an easy matter to create a program that generates that report. Otherwise, I have to somehow create a detailed manifest and include it with the installed files for later reference. Any suggestions? Does Wix or other tool have a built in mechanism for this sort of thing? Thanks.
0
votes
1 Answers
1
votes
It would be useful to know the goal of this, or the potential problem. It's possible that someone believes that the install may have not worked in some sense and therefore there may be missing files or registry entries and needs verification. However MSI installs don't work like that. It either entirely succeeds and installs everything, or fails and rolls back, restoring the system to its previous state (because it's a transaction). In other words, a verification and qualification report that Windows Installer installed the right files is basically getting into the business of testing that Windows works, and most people leave that to Microsoft :).
There are also some practical issues if (for example) there are shared files involved (either yours, Microsoft's, or a 3rd party). If SomeFile.Dll with version 6.0 is already installed at a shared location on the system, and your setup contains SomeFile.Dll version 5.0 being installed to the same location, then your verification tool may report failure - it didn't install version 5.0! Similarly, if you try to overwrite a data file that has been updated then the file will not be replaced, and what verification could be used to check that the "correct" file had or had not been installed? So any potential list of what has actually been installed may be doomed to failure in cases like these. It's also unclear how you would validate (for example) that a service had been installed correctly. If you use (for example) ServiceInstall to install services then is the qualification supposed to verify that the service is installed and that Windows did what it was supposed to do?
If every file in your MSI is marked keypath yes, then one way to inventory the system is to use MsiEnumComponents(), enumerating every installed MSI component on the system. For each of those component Ids, MsiEnumClients() will return a list of the ProductCodes that are sharing the component, and your ProductCode should be one of them. Some will be registry items. I believe there are system management tools that do this kind of system inventory.
A more targeted approach would be to use the Windows Installer SQL APIs to enumerate everything in the Component table of the MSI, and for each of those components do an MsiGetComponentPath(ProductCode, Component guid....) to see where each component is installed and check it's there (and get its version?). Apart from the sharing issues I already mentioned, if the user had a choice of features to install then not everything in the MSI was installed anyway, so the idea of verification means you need to know what features were installed, and filter accordingly, but again, that's testing that Windows did what it was supposed to do.
If you had to verify the installed files against what's in the MSI file, then you'd go through the Component table of the MSI, and:
For versioned files, you'd use the component name to link to the File table of the MSI because it contains the version. MsiGetComponentPath() tells you the path to the installed file that you can call MsiGetFileVersion() on, and compare with the version in the MSI.
For hashed data files, you'd use the component name to look in the MsiFileHash table in the MSI. If there is a hash, get out the four fields and compare with the hash of the installed file (at MsiGetComponentPath).
In other words you don't need the original files because the data is in the MSI file from when it was built.
