Microsoft is rarely the first to jump on a train, but when they do jump, they make sure it is very simple for everybody to get on their wagon. And they did it again with Application Insights, a feature of Visual Studio Online that monitors the performance of web sites, web services, and mobile apps.  They are perhaps not as feature-complete as early players (special thoughts to our friends and partners at Gibraltar Software), but their simplicity is stunning.

Adding Application Insights to Your App

Judge by yourself. You need just two simple steps to add monitoring to your app:

  1. Install the Visual Studio extension “Application Insights Tools for Visual Studio”.
  2. Open your project and click on menu Tools / Add Application Insights.

You’re done. No joke.

Application Insights provides several monitors right out of the box, among which page load time and Windows performance counters. It also has a (still modest) API that allows you to push your own data. Perhaps the top use case you would like to implement is to measure the execution time of a method, and perhaps include the method arguments in the trace data.

Measuring Method Execution Time

Wouldn’t it be nice if you could add your own metric to Application Insights using a custom attribute? This is almost trivial with PostSharp. And since it’s so trivial, it’s also possible with the free PostSharp Express. Let’s see how.

  1. Add the Visual Studio extension “PostSharp”.
  2. Right-click on your project and select “Add PostSharp to project”.
  3. Add a class ApplicationInsightsTimedEventAttribute to the project. For now, just copy the code from this file. I’ll explain what it does in a minute.
  4. Go to the method you want to instrument and add the [ApplicationInsightsTimedEvent] custom attribute.

You’re done.

Run your application and cause the instrumented to execute. Then go back to Visual Studio, and click on menu Tools / Open Application Insights Portal. You’ll see custom timed events triggered by the execution of the method.

A Closer Look At the Aspect

Let’s now have a look at the ApplicationInsightsTimedEventAttribute class itself.

[PSerializable] // Use [Serializable] with the free PostSharp Express.
public class ApplicationInsightsTimedEventAttribute : OnMethodBoundaryAspect
    // Fields and properties will be serialized at build-time and deserialized at run-time.

    string eventPath;
    string[] parameterNames;

    public bool IncludeArguments { get; private set; }

    public ApplicationInsightsTimedEventAttribute(bool includeArguments = true)
        this.IncludeArguments = includeArguments;

        // Make sure it works as expected with async methods.
        this.ApplyToStateMachine = true;

    public override void CompileTimeInitialize(MethodBase method, AspectInfo aspectInfo)
        // Computing the event name at build time since it won't change.
        this.eventPath = method.DeclaringType.FullName
                            .Replace('.', '/').Replace('+', '/')
                            + "/" + method.Name;

        // Collecting parameter names at build time prevents from using Reflection at runtime.
        if (this.IncludeArguments)
            this.parameterNames = method.GetParameters().Select(p => p.Name).ToArray();

    // This code will be executed BEFORE the method to which the custom attribute is applied.
    public override void OnEntry(MethodExecutionArgs args)
        IAnalyticsRequest request = ServerAnalytics.CurrentRequest;

        if (request != null)
            ITimedAnalyticsEvent timedEvent;

            if (this.IncludeArguments)
                // Build a list of properties based on method arguments.
                List<KeyValuePair<string, object>> arguments = new List<KeyValuePair<string, object>>();
                for (int i = 0; i < this.parameterNames.Length; i++)
                    arguments.Add(new KeyValuePair<string,object>( this.parameterNames[i], args.Arguments[i]));

                // Start the event with arguments.
                timedEvent = request.StartTimedEvent(this.eventPath, arguments);
                // Start the event without arguments.
                timedEvent = request.StartTimedEvent(this.eventPath);

            // Store the event in MethodExecutionTag so we can retrieve it in OnExit.
            args.MethodExecutionTag = timedEvent;

    // This code will be executed AFTER the method to which the custom attribute is applied,
    // both upon failure or success.
    public override void OnExit(MethodExecutionArgs args)
        // Retrieve the event. It's possible that there's no event if there was no current request.
        ITimedAnalyticsEvent timedEvent = (ITimedAnalyticsEvent) args.MethodExecutionTag;

        if ( timedEvent != null )
            // End the event.


A specificity of PostSharp is that the aspect is instantiated at build time. This allows for some performance optimizations. Since the event name is fully determined by metadata, it is a good idea to compute it at build time. This is why we have the CompileTimeInitialize method. After the aspect has been initialized, it is serialized and stored as a managed resource in the assembly. At run-time, the aspect is deserialized and is ready to be executed. (Note that the performance optimizations are more significant with a commercial edition of PostSharp; the free edition generates un-optimized instructions).

The OnEntry method is executed at the beginning of any method to which the custom attribute is added. The OnExit method is executed in a finally block after the target method. Their argument MethodExectionArgs contains information about the current context. Here, we’re interested by the method arguments.

Adding the Aspect to Code

Since ApplicationInsightsTimedEventAttribute is a custom attribute, you can add it to any method you want to instrument. Now, what if you want to instrument really a lot of them? You may not want to annotate all of them individually. There are many ways you can do that with PostSharp, but to avoid making this article a PostSharp tutorial, I will just gently send you to the documentation for this point.

Even More Logging

So far, I’ve shown how to add timed events to Application Insights using a very simple custom aspect.

You may want more features for real production-ready logging. For instance, it is important to be able to enable or disable logging dynamically or through a configuration file. Otherwise, the log would just be too huge, so you may want to prepare logging to your complete codebase but disable it by default. Would a problem occur in your app, the operation team would just update the configuration file and enable tracing for a specific class or namespace.

PostSharp has a solution for this: the Diagnostics Pattern Library. It includes a production-ready logging aspect. The bad news is that Application Insights is not directly supported as a back-end. The good news is that we can emit data to NLog, Log4Net or TraceListener, and Application Insights is able to read from all of these frameworks. So, the gap is easily bridged.


Feature Tracking

Nobody said that the concept of “event” must just map to the concept of “logging”. You can use events to model feature tracking too. You could build your own aspect, starting from the code aspect, to implement your own definition of feature tracking and encapsulate it as a custom attribute.


Microsoft Application Insights is stunningly simple to use, but it lacks some features of its competitors. One of them is the ability to instrument your application “from the inside” without requiring you to modify your source code. Fortunately, the feature is very easy to implement with PostSharp.

In the future, we at PostSharp may think of supporting Application Insights directly from the Diagnostics Pattern Library. But before, we’d love to hear your opinion. How do you think we should integrate with Application Insights? What are the top use cases you would like to be solved with the highest level of quality and performance? We’re looking forward to your feedback.

Happy PostSharping!


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 cloud. 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 prevent 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 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 4.0 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 4.0 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 4.0 (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 should 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 4.0 improves multithreading in .NET. More later.

Happy PostSharping!


UPDATE: Change product version from PostSharp 3.2 to PostSharp 4.0.