In article <499e7ecd.8000...@wixtoolset.org>,
Rob Mensching <r...@wixtoolset.org> writes:
> Using conditions to control your CustomAction install/uninstall
> behaviors is primitive and usually insufficient... but the most
> visible. Data driven CustomActions that modify machine state via
> Resources should really use Component states. That matches the design
> of the Windows Installer.
Let me see if I can restate this to make sure I understand what you're
saying.
For data-driven CAs, you would have some association between components
and the custom data (custom columns on the Component table, or a custom
table with a Component relation). The CA executes its install actions
for that custom data when the associated components are selected for
installation and executes its uninstall actions for that custom data
when the associated components are selected for removal.
If that's correct, then yeah, I'd agree that is a better architecture
than making one set of CAs (install, uninstall, rollback, commit) per
component and conditionalizing each CA with the install state of the
component.
Then there are those "the app needs one of these" style CAs, where
they aren't data driven and you need to do a specific thing when the
app is installed, uninstalled, etc.
--
"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
