In the first part of this article, I explained that Silverlight (SL) or Compact Framework (CF) assemblies were not loaded in the CLR. However, as you could have noticed in the last sample, user code still receives instances of Type, FieldInfo, or MethodBase. How is this possible, since assemblies are not loaded, even not "for reflection only"?
Well, here, there is some magic. All these classes (Type, FieldInfo, or MethodBase) are actually abstract ones. You are used to runtime implementations (RuntimeType, RuntimeFieldInfo and so on). But in PostSharp, you don't get runtime implementations (fairly enough, since we are at build time!), so you get so-called reflection wrappers.
Reflection wrappers are an emulation of System.Reflection that purely relies on the PostSharp object model.
Once again to be sure: Reflection wrappers look like System.Reflection but it is not System.Reflection.
And now something even more important:
Even if you target the full framework, you receive reflection wrappers instead of runtime objects.
And this is another big difference between 1.0 and 1.5: 1.0 was not very strict about this; sometimes you received reflection wrappers and sometimes (notoriously in CompoundAspect) runtime objects. In version 1.5, you always receive reflection wrappers.
Gotchaes that will get you
There are subtle differences between PostSharp reflection wrappers and native System.Reflection. If you don't understand them, you risk spending hours in debugging.
- Never compare by reference. That is, never use the equal (==) operator. Unlike native System.Reflection, two instances can represent the same thing. What is more, comparing a wrapper to a native element of System.Reflection never works. So use the Equals method instead of the == operator.
- Never uses native equality or inheritance comparing methods. So don't use typeof(Guid).Equals(targetType) but targetType.Equals(typeof(Guid)). I know this sucks (equality is supposed to be commutative), but... there is no workaround!
The safest way is to use the class PostSharp.Reflection.ReflectionTypeComparer for all comparisons... or when you build a dictionary.
Getting the underlying runtime object
That being said, unless you target SL or CF, you can always retrieve the "usual" runtime/native object and work, well, as usually.
First, let me give you a good reason not to do it: doing so would load the type in the CLR, which would have some performance penalty, and may sometimes not succeed at all (for instance if you have an unresolved extern method -- unresolved because you want to implement them using PostSharp, for instance). It seems that static constructors are not invoked just because of loading the Type object, and I hope (but am not sure) that methods are not JIT compiled. So the reason is maybe good but arguably small, I have to admit.
So if you don't care about the eventual performance penalty, go for it: the secret is to retrieve the property Type.UnderlyingSystemType, FieldInfo.UnderlyingSystemField or MethodBase.UnderlyingSystemMethod. You will get a real-native-runtime-system object.
Since even PostSharp 1.5 loads assemblies in the CLR (when not targeting SL or CF), the difference is maybe slight. But future versions of PostSharp may avoid loading assemblies in the CLR unless strictly necessary. And by requiring the underlying runtime element, you make it necessary... maybe unnecessarily.
Getting the assembly
A problem with reflection wrappers is that Assembly is a sealed class; we cannot override it. So you cannot get a transparent assembly wrapper. So instead of getting an Assembly (typically in a CompoundAspect applied at assembly level), you will get an IAssemblyWrapper. And, yes, you can use IAssemblyWrapper.UnderlyingSystemAssembly if you like.
Pay attention: reflection wrappers are not 'usual' System.Reflection objects!
Setting aside the "exciting new features" of 1.5, there is some fundamental difference between 1.0 and 1.5. Although this difference will hardly be detected by beginners, advanced (PostSharp Core) and even intermediate (advanced PostSharp Laos) ones will surely hit it soon: PostSharp 1.5 is completely independent from System.Reflection.
It has been written that PostSharp Core is built on the top of System.Reflection: this is not true. PostSharp has from the very beginning its own reflection engine, for the good reason that System.Reflection is not good enough for the job. But PostSharp 1.0 relied on reflection for some operations. Indeed, it required every processed assembly to be loaded in the CLR. PostSharp 1.0 read the mapped PE file from memory after it has been loaded loaded by the CLR. A great benefit of this approach is that we don't need to load the assembly twice in memory.
So it was not possible, in PostSharp 1.0, to load an assembly in PostSharp without loading it in the application domain.
The first reason I had to redesign this was Mono: memory mapping of modules was not as clearly defined as in the Microsoft implementation (where the origin of the PE file is simply the HMODULE of module), so it was necessary to read the assembly from disk. But assemblies could still be loaded in the CLR besides, so we could still rely on System.Reflection.
The second and most compelling reason was the support of other variants of the framework, namely Silverlight and Compact Framework. Shortly speaking, it is not possible to load the modules into the CLR, and therefore neither possible to use System.Reflection. It was consequently necessary to make PostSharp completely independent from System.Reflection.
So remember: when using PostSharp for Silverlight (SL) or the Compact Framework (CF), the assembly being transformed is never loaded in the CLR.
Instantiation of aspects in SL and CF
Remember that, when you target the full .NET Framework using PostSharp, instances of aspects are created at build time; they are then serialized and stored as a binary blob as a managed resource.
But how can we instantiate aspects if we cannot load their type? No magic here: we cannot. So we don't. If you target SL or CF, your aspects will be instantiated at runtime and no serialization or deserialization will occur. Period.
You may be curious how aspects are actually instantiated at runtime. Very easily: the PostSharp Laos weaver emits instruction that invoke the aspect constructor with the correct parameters and sets named fields and properties. So finally you get pure MSIL code -- and it is even much faster than deserialization.
Compile-time semantics in SL and CF
A second and more subtle problem is how will work compile-time semantics (like CompileTimeValidate, CompileTimeInitialize and GetOptions). Simply: they cannot be implemented in a SL or CF assembly. CF and SL variants of PostSharp.Laos simply don't contain these methods. There are two kind of workaround:
Custom attributes configuring aspects, for instance classes derived from OnExceptionAspect should be annotated with OnExceptionAspectConfigurationAttribute to specify which exception should be caught (this replaces a build-time call to the GetExceptionType method).
[OnExceptionAspectConfiguration(ExceptionType = "System.SystemException, mscorlib")]
public class ExceptionHandlerAttribute : OnExceptionAspect
public override void OnException(MethodExecutionEventArgs eventArgs)
// Show a dialog box.
More complex logic can be implemented in an assembly built for the normal .NET Framework. So instead of CompoundAspect, you should create a class inheriting ExternalAspect and annotate the class with the ExternalAspectConfigurationAttribute custom attribute. This custom attribute specifies the class implementing the aspect:
[MulticastAttributeUsage(MulticastTargets.Class | MulticastTargets.Struct, PersistMetaData = false)]
public class NotifyPropertyChangedAttribute : ExternalAspect
The implementation class should implement the interface IExternalAspectImplementation, defined in PostSharp.Laos.dll (not PostSharp.Laos.SL.dll or PostSharp.Laos.CF.dll):
You see the similarity with CompoundAspect. There are however some important differences: You don't get the aspect instance because we are not able to create an aspect instance. But you get the object construction (IObjectConstruction), which specifies the aspect type, the constructor arguments, and the named arguments. The second thing is that, as you cannot receive an aspect instance, you cannot create an aspect instance to add it to the collection. So you have to add an ObjectConstruction instead.
Here is the body of ImplementAspect:
public void ImplementAspect(object target, IObjectConstruction aspectData,
// Get the target type.
Type targetType = (Type) target;
// On the type, add a Composition aspect to implement the INotifyPropertyChanged interface.
// Add a OnMethodBoundaryAspect on each writable non-static property.
foreach (PropertyInfo property in targetType.GetProperties())
if (property.DeclaringType.Equals(targetType) && property.CanWrite)
MethodInfo method = property.GetSetMethod();
So writing aspects of intermediate complexity is much less convenient for CF/SL than for the full framework. Good news is that is still possible to do complex things, and that this complexity can be encapsulate so that aspect users actually don't care.
It seems that making ORM easier to work with becomes one of the killer apps of PostSharp.
There were already PostSharp aspects for DataObjects.NET, Starcounter and NHibernate. Sean Kearon has now developed a library for Express Persistent Object (XPO).
For more information, please see the CodePlex project page and his blog.