Hmm, with a little further investigation I think that doesn't make any
sense... the 'metabase' is only an IIS thing isn't it?

 

Nevermind... its been a long day and I've lost my concentration... I'll take
a break (c;

 

-          Adam

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adam Langley
Sent: Friday, 29 June 2007 6:42 p.m.
To: [email protected]
Subject: Re: [WiX-devs] scheduling deferred custom actions for SSRS
publication

 

Hi Bob,

 

I've got my extension doing pretty much everything 'install-wise' that I
need now.

I believe I should delve into the Metabase area of things.

The code in WiX appears only to read from the MSI tables when installing,
but relies on serialized data from the Metabase upon rollback/uninstall, is
that correct (Im making a big assumption around what on earth the 'MetaBase'
is, and what's its for)?

Would you be able to give me a quick rundown on how this works?

I assume looking at the use of the metabase in the IIS CA would be the best
place to understand how to implement it?

 

Thanks,

 

-          Adam Langley

 

From: Bob Arnson [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 28 June 2007 5:22 p.m.
To: Adam Langley
Cc: [email protected]
Subject: Re: [WiX-devs] scheduling deferred custom actions for SSRS
publication

 

Adam Langley wrote: 

Because my custom action is actually modifying the target system (installing
reports), I need to make it a 'deferred' custom action.


Right.



That means that it won't necessarily execute within the confines of the MSI,
hence the custom action may not be able to get a reference to the database
to read the information it needs.


To really explain it I need a whiteboard.<g> Basically, the execute sequence
is broken up into phases. The first is script-generation, when immediate
custom actions run and determine the actions -- and their data. Then the
script is run; that's when you have very limited access to the database and
the installer session it's running in. It's also when CAs get elevated, so
they can modify per-machine data.

There's also rollback, when MSI unwinds the script and deletes files, puts
back overwritten ones, etc. That's why deferred CAs need "matching" rollback
CAs, to undo what they did.

And there's commit, but let's not go there.<g>



Am I on the right track?


Exactly!

-- 
sig://boB
http://joyofsetup.com/
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs

Reply via email to