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
