Yeah, stop the madness. Admit a mistake was made and ship "mandatory updates" to A, B and the already released C's via some other mechanism (Burn bundle?). Then get on to a good path with the new C. Don't bring down your future by trying to dig a deeper custom action hole.
_______________________________________________________________ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -----Original Message----- From: Edwin Castro [mailto:egca...@gmail.com] Sent: Wednesday, May 6, 2015 11:13 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Modifying new msi package prior to recache in a custom action I'll provide more details. I inherited the installer codebase for a product that has released twice (A, B) and was almost ready to release again (C). Releases A and B have poorly written custom actions that cause them to fail occasionally (say 5% of the time) while they are getting uninstalled as part of an upgrade to a newer version (C). We want to fix these issues in C and deliver it as a replacement for A and B during an upgrade. Our original plan was to build C three times. First build would have Release A's ProductCode and ProductVersion (let's call it A' ). Second build would have Release B's ProductCode and ProductVersion (let's call it B' ). Third build would have a new ProductCode and ProductVersion for Release C (let's call this C' ). C' would have A' and B' in the Binary table and we wrote an immediate custom action to extract and recache A' or B' when upgrading from A or B. The we realized that we need to fix pre-releases for C (lets call them C* because there are many). We determined our original plan does not scale well as we'd need a C' for each C* pre-release. The only difference between A', B', and all C' packages would be ProductCode and ProductVersion. Thus we want to build a single C' package to include in the Binary table. In our custom action we want to extract that single C' package to disk, modify the package's ProductCode and ProductVersion to what is currently installed, and recache the package. After I have extracted the C' package to disk I try the following set of calls (error handling omitted): PMSIHANDLE hDatabase = NULL; WcaLog("After previous function call"); WcaLog("Before MsiOpenDatabase(%ls)", wzFileName); er = MsiOpenDatabase(wzFileName, MSIDBOPEN_DIRECT, &hDatabase); WcaLog("After MsiOpenDatabase"); The behavior I see in the log is RecacheExistingProduct: After previous function call MSI (s) (D4:84) [14:23:56:565]: Leaked MSIHANDLE (71) of type 790541 for thread 1380 MSI (s) (D4:84) [14:23:56:565]: Note: 1: 2769 2: RecacheExistingProduct 3: 1 MSI (s) (D4:84) [14:23:56:565]: Note: 1: 2205 2: 3: Error MSI (s) (D4:84) [14:23:56:565]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2769 RecacheExistingProduct: Before MsiOpenDatabase(path\to\C'\package\on\disk) FYI, I also tried MSIDBOPEN_TRANSACT but saw no difference in the log. The wzFileName variable contains the path to the C' package I just extracted from the Binary table. I read online that type 790541 indicates a database MSIHANDLE is getting leaked. I expected that if MsiOpenDatabase was returning an error that was causing my custom action to exit early, then I would see log messages in the cleanup code but those log messages do not show up. Instead the last message that shows up in the log is the message logged BEFORE MsiOpenDatabase is called AND that message appears after MSI logged the leaked MSIHANDLE. To me this seems to indicate something similar to a SEGFAULT occurred causing the immediate termination of the custom action. The MSDN documentation on MsiOpenDatabase at https://msdn.microsoft.com/en-us/library/aa370338.aspx says "Because MsiOpenDatabase initiates database access, it cannot be used with a running installation." Based on the behavior I see in the log I'm interpreting the quote above to mean that I cannot call MsiOpenDatabase in a custom action because custom actions execute within a running installation. I'm looking for confirmation that my interpretation above is correct. I'm having a hard time explaining why I don't see any of the error handling code logging as I expect it to do. I was already using PMSIHANDLE and I know that wzFileName has valid content because the Before MsiOpenDatabase message contains the correct path information. I think my only option is to move this custom action into it's own executable so it is not executing in a running installation. Is this correct? -- Edwin G. Castro ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
