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.

Conclusion

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 Attribute

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).

using PostSharp.Laos;

namespace PostSharp.Samples.Silverlight.Aspects
{
    [OnExceptionAspectConfiguration(ExceptionType = "System.SystemException, mscorlib")]
    public class ExceptionHandlerAttribute : OnExceptionAspect
    {
        public override void OnException(MethodExecutionEventArgs eventArgs)
        {
            // Show a dialog box.
        }
    }
}

External Aspect

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:

using PostSharp.Extensibility;
using PostSharp.Laos;

namespace PostSharp.Samples.Silverlight.Aspects
{
    [ExternalAspectConfiguration(
        "PostSharp.Samples.Silverlight.Impl.NotifyPropertyChangedImpl, PostSharp.Samples.Silverlight.Impl")]
    [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,
                            LaosReflectionAspectCollection collection)
{
    // Get the target type.
    Type targetType = (Type) target;

    // On the type, add a Composition aspect to implement the INotifyPropertyChanged interface.

    collection.AddAspectConstruction(
        targetType,
        new ObjectConstruction(
            "PostSharp.Samples.Silverlight.Aspects.Impl.NotifyPropertyChangedCompositionAdvice, PostSharp.Samples.Silverlight.Aspects"),
        null);

    // 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();

            if (!method.IsStatic)
            {
                collection.AddAspectConstruction(
                    method,
                    new ObjectConstruction(
                        "PostSharp.Samples.Silverlight.Aspects.Impl.NotifyPropertyChangedSetterAdvice, PostSharp.Samples.Silverlight.Aspects",
                        property.Name),
                    null);
            }
        }
    }
}

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.

Happy PostSharping!

-gael

I am pleased to announce I have just released PostSharp 1.5 CTP 2 with exciting improvements over PostSharp 1.5 CTP 1 and of course PostSharp 1.0. Among the things you can be looking forward:

• Aspect Inheritance. This is something many of you have longed for. You can now apply an aspect on a (non-sealed) class or a (non-sealed) virtual method and have the aspect automatically applied to all derived classes or methods. The same with interfaces. Since the feature is implemented at the level of MulticastAttibute. I will blog further about this feature in a next post, but if you are eager to try, everything is hidden behind the MulticastAttribute.AttributeInheritance and MulticastAttributeUsage.Inheritance properties!
• Pluggable Aspect Serializers. If you cannot use the BinaryFormatter to serialize Laos aspects, you can now override the serializer implementation. You can even use no serializer at all and have the aspects constructed at runtime by ad-hoc MSIL instructions. And why would you need to do it? For instance for compatibility with code obfuscators (breaking the relationship between serialization and code), because of an extra need of speed or you need...
• Support for Partial Trust: Since PostSharp Laos is not bound to the BinaryFormatter any more, you can now use assemblies transformed by PostSharp in partially-trusted scenarios. And this may become more important that you now imagine!
• Built-in support for ASP.NET: It used to be available as a separate project; it is now merged in the principal trunk and will be fully supported.
• Injection of Custom Attributes: This new aspect allows you to add custom attributes to any element (type, method, field, method, property, event, parameter, return value, assembly) from a CompoundAspect. See CustomAttributeInjectorAspect for details.
• All the bug fixes up to PostSharp 1.0 SP 1.
• The field injected by a CompositionAspect can be marked as non-serializable.

New features are not yet documented in the user guide (yet they are in the class reference); I will blog about them more in detail during next days.

Happy PostSharping!

-gael

• Runtime performance improvements: Many of you have complained (yes) of poor runtime performance and I have to admin that they were right to a certain extend. A service pack was surely not the place to make great improvements, but I have found some points where little effort resulted in high effect:
  • OnMethodBoundaryAspect do not call "methodof" at each method invocation; this information is cached instead. That is, only if neither the method neither the type is generic! Alex Yakutin (dataobjects.net) measured that the call of "methodof" was the most important performance killer. It has been removed.
  • The same with OnFieldAccessAccess and "fieldof".
  • OnMethodInvocationAspect has now its own and optimal implementation of DynamicInvoke. Microsoft's implementation was shamefully slow since it all relied on reflection. PostSharp now emits optimal MSIL instruction so there is no reflection at all!
• Side-by-side compatibility with the future PostSharp 1.5 CTP 2 due in a few days.
• Breaking change: All PostSharp assemblies have now and will have version 1.0.0.0 (i.e. the build and revision numbers are always zero) and you need to require a specific version in Visual Studio. This was due to the SxS challenge with 1.5. It also means that you won't need to recompile plug-ins for each reversion of PostSharp; it will be enough to do it for each minor version.
• Some annoying problem with debugging experience has been fixed: sometimes the debugging cursor did not really follow the actual code!
• Some less visible issues you can see in our issue tracker.

Szymon Pobiega has just released Micro Container Framework, a dependency injection framework targeting the .NET Micro Framework 3.0.

What does it have in common with PostSharp? Easy! Since this platform typically runs with very limited resource, performance is of paramount importance. There is definitively no time to resolve dependencies at runtime, and there is anyway no support for dynamic compilation.

The solution? Resolve dependencies at compile-time and inject them... using PostSharp! There is not even use of System.Reflection at runtime!

Check this out on CodePlex.

Congratulations Szymon and thank you for this great work!

-gael

Ayende Rayen has just implemented 'static proxies' for NHibernate using PostSharp.

NHibernate is a well-known O-R mapper. One of the features, lazy loading of properties, previously required you to make all properties virtual. The reason is that the properties were "enhanced" (understand: subclassed) at runtime using AOPish techniques. With PostSharp, Ayende now enables lazy loading even.

Ayende did the job in 4 hours:

The first thing that I have to say is wow Post Sharp rocks! And I mean that as someone who is doing AOP for a long while, and has implemented some not insignificant parts of Castle.DynamicProxy. Leaving aside the amount of power that it gives you, PostSharp simplicity is simply amazing, wow!

The feature is now pre-alpha only, but "it works". For more info please refer to Ayende's blog or contact him.

Happy PostSharping!

-gael

As the first stable version of PostSharp has been released for one month, a question arose:

What feature or bug fix is important to you, community? In other words, where should we put our effort?

Finally I've set up a feature voting system: you can vote for a bug or a feature, therefore giving it higher priority. The system is based on 'coins'. Once you create an account on www.postsharp.org, you get 10 coins (existing accounts have been credited of 10 coins as well). You can attribute them to the features of your choice. So you can already start voting immediately!

If you donate to the project, you receive an additional coin for each euro you gave. It does not mean that 1 coin has a value of 1 euro, because I also attribute donations to past efforts and to operational expenses of the project. So to give you an idea, even if coins are not real money, I consider that 1 hour of development should be covered by 100 coins. (Indeed, maintaining and developing PostSharp costs me thousands of euros per month...)

After you make a donation using PostSharp, you will receive an email with a link to a page allowing you to connect the coins. This page requires you to be logged in, so your donation will be assigned to your account.

There is no trick. Coins are not contractual; they are just a way for you to tell me what is important to you, and for me to tell you that the lunch is not free for everyone.

That being said, if you want to make a more significant donation (say >1000 EUR), we can negotiate something contractual, i.e. we discuss what feature will be realized and when. If you are interested by this option, please contact me. For even bigger sponsors, I will set up a partnership program, so you could get the nice status of "PostSharp Silver Partner". Wow!

Anyway. Even if you are not to donate, you are already welcome to vote for features now!

Happy PostSharping!

-gael