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

Tue Aug 22 12:27:26 PDT 2017

Really late reply, but for anybody that was running into the same issue as
me, I am now able to add temporary rows to the Upgrade table
using WcaAddTempRecord()!

I populate a custom MSI table "MyUpgrade" at build time with the same
schema as the standard Upgrade table. Then I have a custom action that
reads all rows from MyUpgrade table and adds them to the Upgrade table
right before the FindRelatedProducts action is executed. Works like a charm!

This allows me to avoid burn falling over when it detects an installed MSI
with an invalid ProductVersion value.

On Fri, Jan 20, 2017 at 6:27 AM, Phill Hogland <phill.hogland at rimage.com>
wrote:

> I found it useful to clone the wixtoolset/wix3 github repository and
> search the wix source for examples of where WcaAddTempRecord is used and
> study that code.  Generally it is important to insert the temporary rows in
> all installation contexts (install and uninstall).
>
> This blog was helpful, although last I looked, the function prototypes in
> the blog are dated and that is where looking at the current wix source was
> helpful.  It is a very worthwhile approach!
> https://www.joyofsetup.com/2007/07/01/semi-custom-actions/
> Semi-custom actions – Joy of Setup<https://www.joyofsetup.
> com/2007/07/01/semi-custom-actions/>
> www.joyofsetup.com
> I was working on my current double-secret project at work and got a
> requirement that I knew would need a custom action. The requirement is to
> add entries to a ...
>
>
>
> ________________________________
> From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of
> Joel Budreau <joel.budreau at gmail.com>
> Sent: Thursday, January 19, 2017 5:48:19 PM
> To: WiX Toolset Users Mailing List
> Subject: Re: [wix-users] Burn error with large MSI product versions
>
> > 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/>
> >
>
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>