For example, I can describe an EXE CA stored in the binary table, scheduled in the execute sequence after InstallInitiatize with no impersonation and deferred execution.
If you have a solid MSI background, you probably have enough information to proceed. But if you are new at MSI and you need me to SHOW you how that all works it can be interesting trying to write it down.
One approach might be to try to describe the table relationships:
Binary Table
NewBinary1 stream in Notepad.exe data here
CustomAction Table
NewCustomAction1 3074 NewBinary1
InstallExecuteSequence Table
NewCustomAction1 1501
I might also try to express the relationships in .IDT format or perhaps MSI2XML ( which InstallShield uses ) but the end result is data that's hard to read and understand. After all, just what the heck is 3074 and 1501 without digging in to understand? Worse, it's not `code` that can be easily stolen ( umm, I mean copy and pasted hehehe ).
<Binary Id="Notepad.exe" SourceFile="notepad.exe"/>
<CustomAction
Return="check" HideTarget="no" Execute="deferred" Impersonate="no"
TerminalServerAware="no" ExeCommand="" BinaryKey="Notepad.exe"/>
<InstallExecuteSequence>
<Custom Action="CustomAction1" After="InstallInitialize" />
</InstallExecuteSequence>
Still, don't expect me to be reading/writing installs like Neo in the Matrix. IMO this is all great, but designers still rule in authoring the majority of my installation logic because of the productivity and reliability gains achieved in automating the authoring.
No comments:
Post a Comment