As I understand in this approach there will be one immediate ca (that will marshal the data to the deferred) and only one deferred custom action that will configure all drivers. If there will be a custom actions for each action to driver, I will have to describe them all in my wixlib. The problem is that I can't schedule only a few deferred custom actions (like InstallDrivers, RemoveDevice, ReinstallDevice) for all drivers because the sequence of drivers' installation also is important (so first I have to run for example InstallDriver, ReinstallDevice for one driver and only after that InstallDriver, ReinstallDevice for another). Also for some drivers actions take different parameters on different conditions (for example on upgrade from one of old versions and on clear installations or upgrade from other versions).
Maybe I misunderstand something and it could be done with WixExtension... But I don't see how. -----Original Message----- From: Blair [mailto:os...@live.com] Sent: Thursday, July 22, 2010 9:15 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Drivers' installation design 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 ------------------------------------------------------------------------------ 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
