You can represent yourself the PostSharp build process as a pipeline through which the input assembly goes. Individual tasks may analyze and/or transform the assembly, which is passed to the next task.
Here are the principal steps of the PostSharp build process (not to be confused with the MSBuild build process, in which PostSharp is integrated).
1. Processing the application-level configuration file
The first step is always to load and process the
application-level configuration file. This file is named
PostSharp-Platform.config and is located in the
principal directory of PostSharp.
The application-level configuration file contains the definition
of tasks that are a part of the PostSharp core. It includes as well
well-known locations to the search path: the application-level
plug-in directory (typically C:\Program Files\PostSharp
1.0\PlugIns) and the user-level plug-in directory (typically
C:\Documents and Settings\<UserName>\Application
Data\PostSharp 1.0).
2. Loading the project file
When the application-level configuration has been loaded, the project file and all referenced plug-ins are recursively loaded. Plug-in files typically define new task types. Note that plug-ins can also be referenced by the application-level configuration file, but it is not the case in the standard configuration.
At this point, implementation assemblies of task types have not been loaded. These assemblies are only loaded when they are needed in a concrete project.
A project contains one of more task instances. The order in which they appear in the configuration file has no importance. The concrete execution order is determined at runtime according to how task types have been configured. Task type definitions can require other tasks to be execute before or after themselves. These required tasks are inserted into the project and properly scheduled.
3. Loading the source assembly and task implementations
When the project file has been analyzed, PostSharp loads the source assembly. Then it instantiates and initializes all tasks included in the project.
In order to resolve assembly references, PostSharp uses the custom assembly resolver.
PostSharp can be configured to use a separate application domain. Using a separate application domain ensures that PostSharp can be executed many times without restarting the main application domain, e.g. typically without restarting Visual Studio. The PostSharp MSBuild task uses a separate application domain, but the command-line utility does not.
4. Executing tasks sequentially
Tasks are executed in the sequence defined in the project loading phase. Concretely, their Execute method is executed.
Tasks may provide other services than simple execution by implementing well-known interfaces. For instance, a task implementing IAdviceProvider can provide the Aspect Weaver with advises. Tasks that implement interfaces are not required to implement the Execute method.
5. Writing back the Code Object Model to the target assembly
Compilation is actually a standard task executed as described above. Note that compilation is not required if no task modified the source assembly.