1 reply to this topic

[mgoedtel]

Hi,

My team and I are working on fine-tuning our packaging standards for MSI Packaged we author in WFWi.  We are trying to get a better understanding of resiliency regarding registry keys (Current User Keys mainly) that may be missing.  We want to be sure that the "repair" works by referencing the MSI in the cache folder, and not by going back to the source where the files reside and try to install any files along with repairing the registry keys.  I have been searching for some good info (besides the MSI SDK and the Web Sites out there) on how the MSI cache really works, and how we can best author our MSI packages to not go to the source where the original package was installed from when "reparing" missing Reg Keys.

We were thinking of creating a separate component that was stricktly for HKCU keys instead of having those entries tied to a file component.  

Thanks and I hope I posted this under the correct forum.

Matt Goedtel

[Ian Blake]

You are on the right track.  Your idea of creating a component just for HKCU is correct.  

When a repair is invoked msi (re-)installls the smallest feature containing the damaged component.  Clearly if this feature contains files the source will be required.  For this reason you will probably require a seperate feature for the HKCU component as well.

When I did this for one of my installations I discovered that my HKCU feature and component were too isolated and repair was not automatically invoked by the shortcuts or com objects that needed the update.  To get around this problem I added a short section of "msi" functions to the start up of a sys tray app I had.  This called MsiLocateComponent to decide if the HKCU was present or not then MsiInstallMissingComponent (after MsiGetProductCode) to trigger the necessary repair.