task is the fine-grained unit of work in the overall setup process.
A task is declarative in nature,
i.e., it describes what needs to be achieved rather than how it's achieved.
Each task is contained within a scope.
The overall setup process involves gathering tasks from various scopes
and then performing those tasks.
Each task has the following properties:
IDattribute. The value of this attribute, if present, must be unique within the containing resource. If the task has an ID, a variable is inferred for each populated String-typed attribute of that task. This variable behaves as if it were logically contained just before the task in the task's container.
excluded triggers attribute
that specifies the triggers for which that task is not applicable.
This affects which tasks will be gathered.
Most task implementations exclude the bootstrap trigger
because they must execute within a running product where the task implementation along with the supporting infrastructure are installed.
As such, task implementations hard-code the
and task authors can further exclude triggers from those that are permissible.
In the end,
by logical exclusion,
this induces an overall set of
disabled attribute that specifies whether or not the task should be gathered.
that specifies the set of scopes to which the task inclusively applies.
predecessors references and a
that specify that tasks that must be performed, respectively, before or after, the task itself is performed.
Furthermore, a task has an intrinsic
priority that is determined by the task implementor.
All these properties affect the order in which tasks are performed.
Each task supports the following operations:
needsto perform as well the logic for
performingthe task. The determination of whether that the task needs to perform is influenced by the trigger, i.e., it affects how detailed will be the analysis for determining whether the task needs to be performed with the general goal being to perform only those tasks strictly needed for the startup trigger. This behavior is documented on a per-task basis.
overriddenby other tasks during the process of gathering tasks. Which tasks are overridden by which other tasks, and how that override merges two tasks into a single combined task is specific to each task implementation and is therefore documented on a per-task basis. A task implement supports overrides by yielding a so called
override token. Two tasks that yield equal override tokens are merged during the initial task gathering phase.
consolidated. At the end of the task gathering phase, each task is consolidated to optimize its representation in preparation before the task is performed.
There are three types of
Bootstrapapplies when using the installer wizard.
Startupapplies when a product is first launched, automated task performance is enabled, and there are tasks that need to be performed, at which point the execution wizard will be opened on the progressPage page.
Manualapplies when invoking the project wizard or directly invoking execution wizard.
Each task specifies its valid triggers determining whether that task is filtered when tasks are gathered.