In article <888080.51646...@web36603.mail.mud.yahoo.com>,
Christopher Painter <chr...@deploymentengineering.com> writes:
>[...] in order to facilitate your snarky comment:
Still no life, I see. For several years now, all you've done is
respond to what I've posted here and in newsgroups with snarky comments.
Wouldn't it be easier for you if you just ignored me? I won't mind.
But back to the issue at hand. If you're already using REMOVE in the
condition for the *deferred* CA, then you don't need to evaluate
REMOVE in an immediate CA in order to set it in the deferred CA's
custom action data property. That's the whole point of why I'm saying
using the custom action data property for this purpose is overkill.
The original question was:
From: "Neil Sleightholm" <n...@x2systems.com>
> I a DTF authored custom action how can you tell the mode it is running
> in, e.g. install, rollback or uninstall?
You don't need to go setting custom action data properties for a CA in
order to conditionalize it for uninstall. Pushing the REMOVE property
into the CAData for that CA is overkill when the CA mechanism itself
already provides a mechanism for conditionalizing custom actions and
executing the right one under the right conditions.
Now that might make you think "but wait! I'll need to duplicate code
in order to have different CAs for the different conditions and
duplicating code is bad!", but this isn't true. Just factor the
common portions out in your CA implementation instead of trying to jam
a single CA into doing all the work. There's no difference in your
code between doing (pseudoC#code)
void mySingleCA()
{
if (immediate)
{
doImmediateStuff();
}
else if (deferred)
{
if (install)
{
doInstallStuff();
}
else if (uninstall)
{
doUninstallStuff();
}
}
else if (commit)
{
doCommitStuff();
}
else if (rollback)
{
doRollbackStuff();
}
}
compared to:
void myImmediateCA()
{
doImmediateStuff();
}
void myInstallCA()
{
doInstallStuff();
}
void myUninstallCA()
{
doUninstallStuff();
}
void myCommitCA()
{
doCommitStuff();
}
void myRollbackCA()
{
doRollbackStuff();
}
Its a design choice. Now, the latter form has a lower cyclomatic
complexity for the implementation of the CA. That means that each CA
code has a simpler control flow and is easier to implement and debug.
Simplicity is good.
It also means that the conditions for the CAs are declared in the
MSI and you can perform more validation on them. For instance, you
could validate explicitly that the rollback action is sequenced before
the action it rollsback and that they both have the same condition.
I've discussed such validation of rollback actions on this list before.
If you cook the conditions into the implementation of the CA, then
this becomes more opaque and you need to write more unit tests on
your implementation in order to keep the validation intact. You also
are separating the condition's evaluation (in the CA implementation)
from the environment that establishes the inputs to the condition (the
MSI/WiX project). Good designs localize concerns together instead of
separating them apart.
But hey, instead of getting to the meat of the matter, its much better
to focus everyone's attention on my snarkiness.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
