Sorry, looks like my email wasn't clear on what happens when. Here's how it
works now (my code didn't change this):
1. First pass at resolving variables.
2. Create Info classes from Rows.
3. Do stuff with Info classes, including setting bind variables.
3. Final pass at resolving variables.
4. Do more stuff with Info classes.
5. Generate manifest using mostly Info classes.
From: os...@live.com
To: wix-devs@lists.sourceforge.net
Date: Wed, 19 Feb 2014 02:43:04 +0000
Subject: Re: [WiX-devs] wixbug:3914 - bind variables in Variable fall through
to the manifest
I haven’t looked at your code yet, but that sounds like a right approach to me.
The other possibility that comes to mind would be delaying generation of the
manifest until early in the final pass after final variable resolution instead
of when it is now. I’m not sure what impact that would have on the code,
however.
Blair
From: Sean
Sent: Sunday, February 16, 2014 5:03 PM
To: wix-devs@lists.sourceforge.net
I submitted a pull request for this bug:
http://wixtoolset.org/issues/3914/
https://wix.codeplex.com/SourceControl/network/forks/seanhall/wixbug3914/contribution/6236
The root cause of this bug is that the Binder uses different classes for
resolving delayed variables and creating the manifest. When resolving
variables, it uses Tables and Rows just like when binding an MSI. But between
the first pass at resolving variables and the final pass, it creates Info
classes which grab the intermediate output from the Rows (there are a few
exceptions where it doesn't create an Info class, like the bundle update row).
It then uses these Info classes to create the manifest. This means that if a
row had a delayed field, then the field would be resolved but the value
wouldn't get into the manifest because the Info class had cached the unresolved
value.
I assumed that we want to continue to use the same code to resolve variables
when binding MSI's and bundles. So I created a VariableRow class, and made the
VariableInfo class store the VariableRow, using the row as the backing store.
There are many of these Info classes. I went ahead and did the same thing for
CatalogInfo. If you agree with this approach and accept the pull request, I
will work on the rest of the Info classes.
Thanks,
Sean
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
