Understanding Aspect Serialization
As explained in section Understanding Aspect Lifetime and Scope, aspects are first instantiated at build time by the weaver, are then initialized by the CompileTimeInitialize method, and serialized and stored in the assembly as a managed resource. Aspects are then deserialized at run time, before being executed.
Because of the aspect life cycle, aspect classes must be made serializable as described in this section.
This topic contains the following sections:
Typically, aspects can be made serializable by adding a custom attribute to the class, which causes all fields of the class to be serialized. Fields that do not need to be serialized must be annotated with an opt-out custom attribute. PostSharp chooses the serialization strategy according to these custom attributes. The serialization strategy is implemented in classes derived from the abstract AspectSerializer class. The default serialization strategy is implemented in the PortableAspectSerializer class, that is backed by PortableFormatter.
This is how you can apply default serialization strategy to your aspect:
In some cases, the default serialization strategy implemented by the PortableAspectSerializer class may not be appropriate for your aspects. For example, the data structures used in your classes may not be supported by the PortableFormatter implementation or you may need your code to be backward compatible with PostSharp 4.2 and earlier. In versions 4.2 and earlier the default serialization strategy was implemented in the BinaryAspectSerializer class, that was backed by BinaryFormatter. You can still use BinaryAspectSerializer as a fallback serialization strategy in PostSharp 4.3 and later.
To apply fallback serialization strategy to your aspects, use [SerializableAttribute] custom attribute instead of [PSerializableAttribute], and use [NonSerializedAttribute] custom attribute instead of [PNonSerializedAttribute].
The BinaryAspectSerializer class is supported only in projects that target the .NET Framework with full trust.
In some situations, serializing and deserializing the aspect may be a suboptimal solution. In case aspect field values are a pure function of constructor arguments and properties, it may be more efficient to emit code that instantiates these aspects at run time instead of serializing-deserializing them. This is the case, typically, if the aspect does not implement the CompileTimeInitialize method.
In this situation, it is better to use a different serializer: MsilAspectSerializer.
MsilAspectSerializer is actually not a serializer. When you use this implementation instead of a real serializer, the aspect is not serialized, but the weaver generates MSIL instructions to build the aspect instance at run time, by calling the aspect class constructor and by setting its fields and properties.
You can specify which serializer should be used for a specific aspect class by setting the property AspectConfiguration.SerializerType of the configuration of this aspect class or instance.
See sectionfor details.
The following code shows how to choose the serializer type for an OnMethodBoundaryAspect:
[OnMethodBoundaryAspectConfiguration(SerializerType=typeof(MsilAspectSerializer))] public sealed MyAspect : OnMethodBoundaryAspect