You are on the wrong track in two ways: 1) the cached msi is a stripped msi, and as a result it can't reliably repair the product, and 2) the registry location you use is undocumented and subject to change and using it is not supported by the Windows Installer team.
The right track consists of copying the original MSI being installed to a "cache" location of your choice and adding that location to the source list of your product either during your initial install (and any other time you recache the MSI) or in your bootstrapper. The copy can be performed by using the CopyFile element in a component, but the source-list change will need to be a custom action that calls MsiSourceListAddSource or other related API (unless your bootstrapper copies the MSI to your cache and runs it from there). -----Original Message----- From: Lian Jiang [mailto:lji...@microsoft.com] Sent: Wednesday, October 21, 2009 10:30 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] repair in add/remove program without the original msi Hi, In our product, after user1 installs the MSI, user1 will remove the original MSI and then give the machine to user2. For example, the user1 installs the MSI from a remote share and user2 will have no access to the remote share. This will disable "repair through add/remove program" for user2 because he cannot get the original MSI. However, "repair through add/remove program" is a must for user2. After reading MSDN<http://blogs.msdn.com/windows_installer_team/archive/2006/05/24/605835. aspx>, I decides to make "repair through add/remove program" use the cached MSI instead of the original MSI used to install. The cached MSI location is stored in this registry value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserD ata\S-1-5-18\Products\{SomeGuid}\InstallProperties\LocalPackage. The value is something like: c:\windows\installer\157efa1.msi. "S-1-5-18" = SID for LocalSystem and {SomeGuid} is the Package Guid. I don't know where the package guid is generated from but I observed that it is consistent across machines. Can I safely assume the guid is constant for my product? The AppWix.cpl picks the MSI path from LastUsedSource registry value and package name PackageName registry value from HKEY_CLASSES_ROOT\Installer\Products\{SomeGuid}\SourceList. So if I use the cached MSI's location and name to replace the LastUsedSource and PackageName respectively, I can repair through add/remove program without the original MSI. However, the downside is that everytime after I repair, the cached MSI's name changes (e.g. 157efa1.msi changes to 33ef.msi). This requires that I do the registry change everytime I repair to make "repair through add/remove program" always points to the lastest cached MSI. Are we on the right track? Is there any better/safer way to achieve "repair through add/remove program without original MSI"? Appreciate your help! Thanks Lian ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
