The WixExtension can supply a compiler extension to implement your schema
for your pattern (allows you to easily describe what is being installed) and
should populate your custom table that your custom actions use to control
their work. It should also create a reference to the fragment in your wixlib
where each custom action set is declared and scheduled, so you don't have to
expose that to your authors. Your table should include a foreign key to the
Components table so that you can use the installation request states of
those components to facilitate your install/remove/upgrade/repair
determinations.

Each custom action should then read the table(s) and marshal the data to the
deferred, rollback, and commit (if needed) actions.

Organized that way, it should be easy to use, easy to test, and easy to
maintain.

-----Original Message-----
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Thursday, July 22, 2010 7:18 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Drivers' installation design

I would use a WixExtension. Why didn't that seem to work?

On Thu, Jul 22, 2010 at 1:43 AM, <vazhenin_mak...@emc.com> wrote:

> I work on WiX-based installer for large product, we need to install 16
> drivers (of 3 different types, so there is 3 installation patterns).
> Difx library is not flexible enough, so we have our own tool to install
> drivers. For each driver necessary to run this tool about 3  times (for
> example: remove phantom devices, install disk driver, remove root
> device), and some of these actions required rollback. So there are about
> 5 types of custom actions (install, uninstall, remove, reinstall,
> repair) with different parameters. Write ~50 custom actions for all
> drivers isn't a good decision, because it's very hard to support this
> code.
> What is the best solution to describe a complicated installation
> process?
>
> I already tried the following decisions:
>    - preprocessor cycles. Code becomes compact but very hard to
> understand.
>    - compiler extension (to describe each type of custom actions). This
> is useful but still  I can't write an installation pattern with it.
>    - preprocessor extension. This seems to be the best solution (also
> using compiler extension). I wrote preprocessor functions like
> "InstallDriver(Inf=[#mpio.inf], RootDevice=MPIO, Execute=onInstall,
> Condition=$(var.InstallCondition))"
> and define the installation sequence in a variable:
> <?define
> Actions=InstallDriver(...);RemoveDevice(...);ReinstallDevice(...)?>
> then include a .wxi file with default parameters and required custom
> actions' definitions.
> But in these approach there is a problem with custom actions' names
> (where to define them? in function parameters isn't very clear, randomly
> like " CA_InstallDriver.mpio.9fdcd3f3e45e45e8944194884abf2708" also
> isn't good, because in every build custom actions will have different
> names...).
>    - custom table and immediate custom action to add deferred custom
> actions for all drivers. It also seems good but it's hard to debug.
>
> Will be grateful for any suggestions.
> Thanks,
> Maks.
>
>
>
----------------------------------------------------------------------------
--
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC
----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to