The WixMbaPrereqPackageId variable is only used at build time to fill
out the WixMbaPrereqInformation table in the BA manifest. It's all done
in authoring, not extension code: see
src\ext\BalExtension\wixlib\Mba.wxs. Normally it has only one row but
you could use the same table instead of adding a new one. That would let
WixMbaPrereqPackageId keep working if it's used. Otherwise, your changes
to the compiler extension would keep adding rows like it does in the
pull request, just to the existing table. And the NetFxExtension library
could use that attribute instead of the variable.
Off the top of my head, that should work ok and it eliminates the
duplication between having one "special" prereq package and <n> others.
On 18-May-14 18:38, Sean Hall wrote:
It's definitely silly :)
I think the best thing to do is to change the implementation of the
WixMbaPrereqPackageId variable to look the same to the Prereq BA,
which was probably what Rob was trying to tell me. To be fully
backwards compatible, the Bal extension could add an attribute that
says to always install the package. This attribute wouldn't be
exposed to the user, and setting this variable in v4.x wouldn't do
anything.
However, I don't know how to do this. This was the first time I had
messed around with a compiler extension. How would the Bal extension
find out that the variable was set so that it could add that packageId
to the table?
On Sun, May 18, 2014 at 2:19 PM, Bob Arnson <[email protected]
<mailto:[email protected]>> wrote:
On 16-May-14 20:23, Sean Hall wrote:
> I thought the goal was to be able to compile your existing
project on
> the next version and everything work like before. There could be
> someone who set their .NET package InstallCondition to "0 = 1", and
> then it would be different.
We reserve the right to laugh at people doing silly things. Is that a
silly thing? Seems like it. I can see it as an attempt to prevent
repair
but obviously removing @RepairCommand is better.
If it's not silly, then we need a "force" option.
My previous comments were to indicate that we should use the same
mechanism to support all the pre-req packages rather than treating
WixMbaPrereqPackageId differently than the support packages.
--
sig://boB
http://joyofsetup.com/
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing
platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
WiX-devs mailing list
[email protected] <mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
--
sig://boB
http://joyofsetup.com/
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
