[wix-users] Burn error with large MSI product versions

[Joel Budreau]

> For my situation, it seems like a good approach to remove the references from the Upgrade table, and simply add them in at run time. Thanks for the suggestion :)
I’m running into a problem with this solution and I can’t figure out if I’m missing something, or this just won’t work…

1. At build time, I create a custom table named “CustomUpgradeTable” where I move my problematic rows to from the Upgrade table.
2. I have an immediate custom action that copies all rows from CustomUpgradeTable -> Upgrade table (adding “TEMPORARY” to the end of the SQL insert query).
3. I schedule this custom action to run right before FindRelatedProducts.
4. FindRelatedProducts doesn’t find the product identified from the CustomUpgradeTable :(

I’m wondering if I’ve correctly updated some instance/copy of the Upgrade table in memory, but the FindRelatedProducts action ignores that and just reads the original file contents? I assume that what I’m trying to do it possible because I hear about people using this kind of solution to populate the Registry table a runtime…

Any help would be great, thanks :)

(If all else fails, I’ll just drop those problematic products from the the Upgrade table and write custom actions to see if they’re installed or not)

- Joel

> On Jan 17, 2017, at 9:46 AM, Joel Budreau <joel.budreau at gmail.com> wrote:
> 
> For my situation, it seems like a good approach to remove the references from the Upgrade table, and simply add them in at run time. Thanks for the suggestion :)
> 
> On Fri, Jan 13, 2017 at 11:56 PM, Blair Murri <osito at live.com <mailto:osito at live.com>> wrote:
> There's an ICE error/test for invalid version values. While there may be a way to transform an invalid version value into a testable one, since the way that the versions are stored/compared by the Windows Installer APIs isn't documented, and since the method of storage has changed during the evolution of MSI/Windows, it would be a fools errand to even try.
> 
> 
> 
> If you have control over the other products’ packages then I recommend you fix their “package product” versions to conform. If you really don't have to care what the version is of the other products are, remove the version string. If you don't need to know about the other product in the BA, don't add it directly to the MSI’s Upgrade table (so that the BA doesn't even see it), instead adding it to that table at runtime. If you need to know the specific version in the BA, again don't put it directly in the MSI’s Upgrade table, instead write code directly in the BA (I recommend storing the data in a custom table in the BA) to enumerate by upgrade code and parse/compare version codes yourself based on whatever intent you can determine from whomever generated the invalid version strings.
> 
> 
> 
> Good luck to you. Let me know if I can help.
> 
> 
> 
> Sent from my Windows 10 phone
> 
> 
> 
> From: Rob Mensching<mailto:rob at firegiant.com <mailto:rob at firegiant.com>>
> Sent: Friday, January 13, 2017 12:15 PM
> To: WiX Toolset Users Mailing List<mailto:wix-users at lists.wixtoolset.org <mailto:wix-users at lists.wixtoolset.org>>
> Subject: Re: [wix-users] Burn error with large MSI product versions
> 
> 
> 
> The other package's version is not just too large, it's completely invalid: https://msdn.microsoft.com/en-us/library/windows/desktop/aa370859(v=vs.85).aspx <https://msdn.microsoft.com/en-us/library/windows/desktop/aa370859(v=vs.85).aspx>
> 
> _____________________________________________________________
>  Short replies here. Complete answers over there: http://www.firegiant.com/ <http://www.firegiant.com/>
> 
> -----Original Message-----
> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org <mailto:wix-users-bounces at lists.wixtoolset.org>] On Behalf Of Joel Budreau
> Sent: Friday, January 13, 2017 12:13 PM
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org <mailto:wix-users at lists.wixtoolset.org>>
> Subject: [wix-users] Burn error with large MSI product versions
> 
> I have an MSI that I want to package into a burn bootstrapper. My MSI has
> UpgradeCode references to a different product. I only want to detect if the
> other product is installed or not. When I run my custom BA I see the
> following log message:
> 
> Error 0x800200a: Failed to convert version: 3.6.0.4208657 <tel:3.6.0.4208657> to DWORD64 for
> ProductCode: ...
> Detect failed for package: <my package> ...
> 
> So, it looks like the detect phase of my new bootstrapper will fail because
> some other product is using a build number that's too large.
> 
> What's the recommended workaround here? Use some other mechanism besides
> the Upgrade table to detect if the other product is installed?
> 
> Thanks,
> Joel
> 
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/ <http://www.firegiant.com/>
> 
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/ <http://www.firegiant.com/>
> 
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/ <http://www.firegiant.com/>
>