At Build 2014, Microsoft announced Project Orleans, an implementation of the Actor model for .NET and Azure. With theoretical foundations laid in 1973, this programming model can hardly be considered a newbie. The choice of the project name itself is heavy of history – Orleans, a French town south of Paris, was an important Gallic center before being conquered by the Roman empire.

Actors are at the root of the success of the Erlang language. Erlang has been developed by Joe Armstrong of Ericsson in 1986 to build telephony infrastructure applications such as switches. The language has been open sourced in 1998.

Initially designed for niche applications, the actor programming model became more popular with the end of Moore law and raise of multi-core machines. The turn to cloud computing and the generalization of distributed architecture finished to bring the actor model into the mainstream spotlight.

Orleans is not the first actor framework for .NET. The NAct open-source project has been there for almost 4 years, and PostSharp has provided an implementation for 2 years.

Horizontal scalability

Yet, Orleans is a significant release. It is the first actor implementation that really focuses on horizontal scalability. White both NAct and PostSharp Actor were limited to organizing concurrency within a single process, Orleans has been built from the ground up to cross the machine boundary and scale up to the could. Orleans is the first to be a real actor platform, not just a framework. The primary production environment of Orleans is Windows Azure. You can run it in-process for testing purposes, but the primary usage scenario is to deploy it on the cloud.

The cloud-first objective underpins many decisions of Orleans. In this article, I will try to compare Orleans to PostSharp Actors. But first let me do the usual full disclosure: I am the principal developer behind PostSharp Actors and we sell it commercially.

Invocation technology

It would be tempting to say that Orleans is a run-time technology and PostSharp a build-time one, but this would be incorrect. The two products include both a run-time and a build-time part. Yet, PostSharp is quite thin at run-time, and Orleans’ build-time functionalities are more limited.

When an actor method is invoked from the outside, the actor framework first needs to pack the method call (i.e. the identity of the actor, the identity of the method being invoked, and its arguments). Then, the message is appended to a queue. At the other end of the queue, the actor framework dequeues the message, unpacks its arguments, and invokes the target method on the actor itself.

Orleans and PostSharp do this in a very different manner. However, both involve build-time code generation.

In Orleans, actors must expose their functionality as an interface. When you compile an Orleans project, the framework will generate two classes for each actor interface: one client-side proxy implementing the actor interface and deriving the GrainReference class, and one server-side invoker that unpacks the messages and invokes the actor class. Typically, actor interfaces are defined in a standalone project that is shared by both the client and the server; both generated proxies live in the same project as the interface itself.

PostSharp relies on the MethodInterceptionAspect, which does something similar (packing and unpacking arguments) but without introducing new classes. Under the cover, PostSharp uses sorts of “proxy methods” that don’t change the class hierarchy. Therefore, client code can refer to the Actor class directly instead of going through an interface. This may seem a minor benefit for this specific scenario; you can still use an interface if you want, it’s just that you are not required to do it.

So, both Orleans and PostSharp rely on build-time generation of proxies and invokers. Orleans does it before compilation using a code generator, while PostSharp does it after compilation.

Model validation

The core idea of the actor model is to avoid shared mutable state by ensuring that the actor’s private state is accessed by a single thread at a time. To ensure thread safety, user code must respect a set of rules. For instance, all methods must be asynchronous, all fields must be private, and the private state must not be made available to other threads in any way.

Orleans and PostSharp are very different to this regard.

Orleans has some basic validation of user code against the model. For instance, if the actor interface contains a method whose return type is not a Task, you will get a build-time error. However, Orleans does not validate that the implementation is really asynchronous. In .NET, it’s possible to create a method that does some work synchronously before returning a Task. Orleans documentation warns you that this scenario is erroneous and you should only use methods made asynchronous by the async keyword, but no build-time or run-time error stops you when you’re doing a mistake. Instead, you will get random data corruption. Errare humanum est, but in the case of multi-core programming, any mistake that is not detected in a deterministic way is likely to be disproportionately expensive to diagnose. Neither does Orleans prevents your fields to be public or your private fields to be accessed from another thread without going through the message queue. In short, Orleans makes you responsible to write good code, and will work fine if you respect all rules.

Model validation is at the heart of PostSharp’s approach of multi-threading. PostSharp takes the assumption that to make errors is human and a better strategy is to decrease the cost of human errors by detecting errors earlier and deterministically. Some errors (like having a public field) would be detected at build-time. Other errors, like accessing the actor state from the wrong thread, can be detected only through run-time analysis. To achieve this, PostSharp checks the calling thread whenever a field is accessed. And because PostSharp has a notion of parent-child relationship, we are able to do that even for deep children of the object. Of course, runtime validation comes at a performance cost, so it’s enabled by default only in the debug build.

Thus, Orleans and PostSharp differ very significantly in their approach to model validation. One is more like C, the other is more like C#. You can do more with the first, but the second is safer.

Orleans unique features

The biggest difference between Orleans and PostSharp Actors is that Orleans can scale across machine boundaries. Not only the actors can communicate over the network, but actors can move from one to another machine, which makes it possible to dynamically add nodes to an Orleans cluster, and automatically distribute the load to them.

This objective underpins other another design concept of Orleans. The state of an actor is kept in a persistent storage. The lifetime of an instance of an actor class does not match the lifetime of the actor itself. Instead, an instance of the class is created whenever an actor needs to be activated; the state of the actor is then deserialized and assigned to the actor instance. When an operation finishes, the state of the actor is serialized and saved back to the storage.

Orleans implement this design by requiring actor persistent state to be stored in a separate object, exposed as a separate interface. By comparison, the state of the actor in PostSharp is stored in the fields of the actor class itself, which is a more natural programming model.


Orleans and PostSharp Actors build on different visions: Orleans focuses on scaling horizontally on the cloud, while PostSharp limits itself to in-process concurrency and puts more energy into validating the code for thread safety. Different objectives lead to different designs, and this article tried to highlight the most important differences between both implementation.

Could we have a unified actor programming model for .NET, which would work great and naturally for in-process computing but would robustly scale to the cloud? I’m not convinced that a wedding between Orleans (best at scaling) and PostSharp (best at programming experience) would be a perfect one, but I do think both could learn from each other. PostSharp could learn to integrate with Orleans, and Orleans could do more model validation, for instance by delivering a ruleset for Microsoft Code Analysis.

The good thing is that you don’t need to switch to a new language or platform to use actors.

Happy PostSharping!


Immutable are popular for a good reasons: they are totally thread-safe. Immutablity accounts for the bigger half of functional-language hype, to a point that some Robert Martin raised his voice to obliterate assignments from the programming landscape. At PostSharp, we don’t share this unconditional passion for the all-functional movement, and we think that object-oriented programming is still the most relevant paradigm for most applications. We don’t think .NET people should mass migrate to F# or Clojure, but we do think we can do C# better. Improving C#: that seems a good mission for us, and it’s what we did with the Immutable Object pattern and his milder brother, the Freezable Object pattern.

NOTE: This blog post is about an available pre-release of PostSharp. You can install PostSharp 3.2 only using NuGet by enabling the “Include pre-release” option.

Why the readonly keyword is not the solution

Let’s face it, the Immutable pattern is quite impractical to implement in C#. Many believe that making a class immutable means to make all fields read-only; this is both unnecessary, insufficient and impractical:

  1. Read-only fields are not necessary for a class to be immutable. In C#, the read-only modifier prevents a field from being changed from another method than a constructor. This is a well-known frustration for C# developers that you cannot set a read-only field from a method, even if this method is invoked only from constructors.
  2. Read-only fields are insufficient to make a class immutable if fields themselves are not of an immutable type. For instance, an Invoice class is not immutable if it has a lines field whose type is List<InvoiceLine>, even if the field itself is read-only. However, an invoice can be immutable even if it has a customer field of type Customer and the Customer class is mutable. So, why is it a problem for the List class to be mutable but not for the Customer class? Because of the type of relationship materialized by the fields: the customer field implements a reference, but the lines field implements a child relationship. Only children of immutable objects must be immutable.
  3. The vanilla Immutable pattern is impractical in many scenarios of object-oriented programming because it often happens that an object needs to be initialized in several steps, not just using a constructor. For instance, data transfer objects (DTO) should typically be immutable but should also be serializable, two apparently conflicting requirements.

Immutability is an important pattern, but implementing it in pure C# is cumbersome.  So we decided to do something about it.

Designing a Better Immutable Pattern

In my opinion, conventional object-oriented literature makes a fundamental mistake when talking of immutability: it refers to immutable objects, but instead it should refer to immutable aggregates. According to the UML terminology, aggregates are sets of objects that are in a parent-child or whole-part relationship. Typically, immutability applies to whole object trees (or parts of the tree), not just to one object. This remark may seem academic but it means a programming language cannot tackle the notion of immutability without a notion of parent-child relationship (unless all types are immutable, but then you get a functional language). Children of immutable objects should also be immutable, otherwise we loose all guarantees of immutability.

So, if we want to do immutable well in a object-oriented language, we first need to add a notion of parent-child relationship. This is exactly what we did in PostSharp 3.2 with the Aggregation Pattern. Now you can see why we spent so much energy into this pattern. This was not just for undo/redo. We could not do multithreading well without a good aggregation pattern.

Freezability is immutability’s milder brother. Instead of forbidding changes in the object after the constructor has completed, we define a Freeze method and allow changes until this method has been called. The Freeze method can be invoked automatically, for instance after deserialization, or manually. Note how freezability is related to the Aggregation pattern: when you freeze a parent, you expect all children to get frozen as well.

Now, let’s put immutability, freezability and immutability together. I said above that classes of immutable entities must have fields of an immutable type. This was imprecise: actually, it is acceptable for an immutable class to have fields of a freezable type, as long as freezable children get frozen when the parent constructor completes. So, it is enough for just the aggregate root to be immutable; children can comply to the milder requirement of being freezable.

Immutability and Freezability in PostSharp

I though a bit of theory would be beneficial even beyond the audience of PostSharp users.  Now, let’s see how this works in practice.

PostSharp 3.2 (specifically, the PostSharp.Patterns.Threading package) provides two aspects: [Immutable] and [Freezable]. These aspects implicitly require and add the previously described [Aggregatable] aspect, which adds a notion a parent-child relationship to your code through the custom attributes [Child], [Reference] and [Parent].

The following code example shows several classes in a parent-child relationship. We want the Invoice entity (including its children lines and discounts) to be freezable, but the InvoiceDocument class, which represents a stored invoice, must be immutable.

public class Invoice
    public readonly AdvisableCollection<InvoiceLine> Lines = new AdvisableCollection<InvoiceLine>();

    public readonly AdvisableCollection<InvoiceDiscount> Discounts = new AdvisableCollection<InvoiceDiscount>();

    public Customer Customer;

    public static Invoice Deserialize(Stream stream)
        // Details skipped.

public class InvoiceLine
    public Product Product;

    public Invoice ParentInvoice { get; private set; }

[Freezable] public class InvoiceDiscount { public decimal Percent; public string Reason; [Parent] public Invoice ParentInvoice { get; private set; } }

[Immutable] public class InvoiceDocument { string fileName; [Child] public Invoice Invoice; public TextBuffer( string fileName ) { this.fileName = fileName; using ( Stream stream = File.OpenRead(fileName)) { this.Invoice = Invoice.Deserialize( stream ); } } }

To freeze an object, you shoud first cast it to the IFreezable interface using the QueryInterface<IFreezable>() extension method, for instance:


Model Validation

That said, you may argue that the C# language and the OOP practice has good reasons to identify immutability to the use of read-only fields. This reason, indeed, is that the compiler is able, in a very straightforward way, to give a 100% guarantee, at build time, that the object is immutable. I’ve already expressed that I don’t think this guarantee is very useful, but let’s at least acknowledge that the compiler gives you this guarantee. Being optimized for usefulness, PostSharp has a different approach. It is impossible to perform a 100% build-time validation of the relaxed immutability model that it implements, at least not within acceptable build time. Instead, PostSharp relies on runtime model validation: if you try to modify an object after it has been made read-only, you will get an ObjectReadOnlyException. Of course, these runtime validations come at some performance cost, and this is why they are only enabled in debug build by default. Note that the current version of PostSharp does not perform any build-time validation of the model; even if we could do a say 80% build-time validation at reasonable cost, this analysis is not currently implemented.

The following code shows how the InvoiceDocument and Invoice classes may be used, and how modifying the objects would throw a ReadOnlyObjectException:

InvoiceDocument invoiceDocument = new InvoiceDocument("invoice.xml");
// The following line throws an exception because InvoiceDocument is immutable.
invoiceDocument.invoice.Discounts.Add(new InvoiceDiscount { Percent = 5, Reason = "Early bird" });

Customer customer = new Customer { Name = "Michael Jordan" };
Product product = new Product { Name = "Cello" };
Invoice invoice = new Invoice { Customer = customer };
invoice.Lines.Add(new InvoiceLine { Product = product });


// The following line throws an exception because Invoice has been frozen.
invoice.Discounts.Add(new InvoiceDiscount { Percent = 5, Reason = "Early bird" });


The orthodox Immutable Object pattern is not fully appropriate to object-oriented programming because the rules it relies on (all fields must be read-only) are insufficient, unnecessary, and impractical. Instead, I proposed a relaxed version of the Immutable Object, which teams with the Freezable Object Pattern and the Aggregation Pattern to provide a more useful construct. The caveat of the relaxed Immutable Object pattern is that it cannot be validated with 100% certainty at build time, but it is fairly easy to enforce it at runtime.

PostSharp implements these concepts through the [Immutable] and [Freezable] aspects, which implicitly rely on [Aggregatable] and require you to annotate your fields with the [Child], [Reference] or [Parent] custom attributes.

This is one more example that adding a concept of parent-child relationship to the language helps solving many problems.

But we just scratched the surface of how PostSharp 3.2 improves multithreading in .NET. More later.

Happy PostSharpin!


A couple of weeks ago we announced our PostSharp 3.2 makes it much easier to implement undo/redo in your app. We didn’t want to publish the feature before giving it a serious try, but didn’t have an internal app to dogfood. So we looked for an open-source project that would greatly benefit from the feature. We selected VisualDesigner, a framework to build graphical editors as PowerPoint, Visio or Blend. VisualDesigner is hosted on GitHub and released under the permissive MS-PL.

VisualDesigner is being developed by José Manuel Nieto (@SuperJMN). José works at DocPath, building software to help customers to design and create dynamic documents. With years of experience in graphical editors, he understands that visualization and UI interaction are very important to DocPath’s product line. You can find José’s contact info on his GitHub profile page.

We asked José to talk about his project.

Jose Manuel Nieto

How did you come to the idea of creating VisualDesigner?

It all started as one of my many side projects. As part of my experience, I have seen that visual designers have a lot of potential. A great number of applications can benefit in a way or another from this concept. I realized that there was almost no information about how to develop a visual designer from scratch and most importantly, doing it the right way. Only a few basic samples, incomplete and not generic enough to be a solid start for others to make their own designers in a MVVM way. I took it as a challenge and felt I had enough knowledge to make something useful out of it while enjoying my passion for development.

Tell us more about VisualDesigner.

It’s a little framework that enables anybody to develop their own designer in minutes. It solves the most common scenarios in a designer and can be extended easily. It’s made specifically to apply the MVVM pattern.

The project consists of several libraries and 2 demo applications. One is a WPF demo. It was the first I developed.

WPF Demo App

Picture 1 WPF Demo application

As most of the code is shared through a Portable Class Library, it was very easy to create a demo application using other Windows platforms like Windows RT.

The Window RT demo is a very basic comic creator. You can drop a sample character, add speech bubbles and frames. You can also modify their properties like text, fonts, colors…

Picture 2 Windows Store Demo Application

90% of the code is shared, and it works out of the box, that it’s a very good thing.

What are the principal features of VisualDesigner?

I think the most important feature is that it’s domain-agnostic. It doesn’t require you to modify your model to work as expected.

Talking about the different operations that can be applied to a design, it features:

  • move, resize,
  • group, ungroup,
  • bring to front, send to back,
  • snapping, undo/redo.

It supports WPF and WinRT through Portable Class Librairies.

Picture 3 Snapping to edges is a nice feature

What were your architectural/design priorities?

As a die-hard Clean Code follower, I think that source code should be written to be read, not to be deciphered. I put emphasis in best practices and principles to make it robust and easy to understand. Also, having a clean domain model is a top priority for me. I come from applications developed from a Domain-Driven Design perspective and my natural tendency is to keep the model as the true protagonist.

For instance, take a look at this class:

public class SpeechBubble : Shape
    public string Text { get; set; }

    public Color TextColor { get; set; }

    public double FontSize { get; set; }
    public string FontName { get; set; }

It’s what we call a POCO. It cannot be clearer. It is part of the model, and in VisualDesigner we can work with instances of SpeechBubble directly on a DesignSurface without adding anything else.

How did PostSharp help achieve better code?

PostSharp has a wide variety of features that can improve the quality of the code. The NotifyPropertyChanged aspect is particularly useful when working with the UI.

    public sealed class DesignSurface : ListBox, IDesignSurface

Marking a type with this annotation (aspect) makes PostSharp to automatically raise the PropertyChanged event whenever a property changes.

It’s really nice to see that this feature works in perfect consonance with the rest of the features, like Undo/Redo. This is especially valuable. A solid Undo/Redo mechanism can be quite hard to develop and always needs to add a lot of extra code in the model. PostSharp provides it and works without any hassle. It works recording changes in the state of the objects using aspects. The Recordable aspect indicates to PostSharp to record a history of changes made to instances of that type:

Look at this snippet.

    public class CanvasModelItem : CanvasItem
        private readonly CanvasItemCollection items = new CanvasItemCollection();

        private ICanvasItemContainer parent;

Later, you can use the Recorder object to go to previous states.


It is as simple as it seems. In the snippet you can also see other interesting annotations: Child and Parent. It helps to automate the aggregation relationship between instances.

How did you handle undo/redo “continuous operations” like move or resize?

It’s very common to find operations that raise a big amount of changes in a period of time. For instance, when the user drags an item its coordinates change continuously while the user moves the item with the mouse. We may not want all those changes to be recorded so each time a continuous operation starts, we can define a “recording scope”. This way, the recorder will know that changes between the start and end signals in the scope should be ignored. Then, the operation can be undone (or redone) as a whole, in an atomic way, that is a more convenient and useful. Otherwise, the recorder history would be filled with irrelevant changes.

For instance:

        private void Rectangle_PointerPressed(object sender, PointerRoutedEventArgs e)
            if ( this.recordingScope != null )
                throw new InvalidOperationException("There is already an active recording scope.");

            this.recordingScope = RecordingServices.DefaultRecorder.StartAtomicScope();
            bDetectColor = true;

This event handler is called when the user click (or presses in a touch screen). You can see the StartAtomicScope being called. It signals makes the Recorder aware of the operation about to begin.

        private void Border_PointerReleased(object sender, PointerRoutedEventArgs e)
            if (this.recordingScope == null)
                throw new InvalidOperationException("There is no active recording scope,");

            GetHue(sender, e);

            bDetectColor = false;

            this.recordingScope = null;

This is the complementary handler that is called when the user released the mouse/finger. The recording scope is set to complete calling the Complete() method. As simple as it sounds.

What is the next thing you would like to focus on?

At the moment I’m thinking of a version 2.0 of VisualDesigner. I know that some code can be simplified and improved. The current version was thought to be a WPF application, using a whole set of features that are specific to the platform. When porting to WinRT I had some difficulties that exposed some weaknesses of VisualDesigner itself. For example, the concept of Adorners don’t exist in WinRT, and the current code relies on them to provide visual aids like handles and snapping guides to the user. It will be even easier to use and to extend, and since I have PostSharp from the beginning I’m sure the development will be faster and the code cleaner and way easy to understand.

I want VisualDesigner to become a great tool and a sample about how to deal with some complex topics. If it works for me, it would work for somebody else. I’m always proud to collaborate with the community and I want to give my best to other people. So yes, a new and improved version will be the next step.

Thank you, José. Happy PostSharping!



This article is part of a series of 5 about undo/redo:

  1. Announcement and introduction
  2. Getting started – tutorial
  3. Logical operations, scopes, naming
  4. Recorders, recorder providers, callbacks
  5. Case study: Visual Designer

NOTE: This blog post is about an available pre-release of PostSharp. You can install PostSharp 3.2 only using NuGet by enabling the “Include pre-release” option. Undo/Redo is implemented in the package PostSharp.Patterns.Model.