Gabriel Schenker's Blog

Fluent Silverlight – Binding control events to actions

Gabriel N. Schenker — Wed, 27 Jan 2010 14:01:43 GMT

Please view the table of content of this series for reference.

Introduction

A typical Silverlight application (or any application with a GUI) contains elements or controls like command buttons , menu items, text boxes etc. The user of the application interacts with the system via these controls. When the user interacts with a control like a command button this control raises events. In the case of a command button this would most probably be the Click event; in the case of a text box it might be the TextChanged event. As a developer we want to react to those events; we want to have some action happen as a consequence of the user clicking a button.

Sample

Let’s call the element that raises an event a publisher. So we can implement a Publisher class with one event BookReady. This event is raised whenever the publisher has a new book ready. The code looks like this

public class Publisher

    public event EventHandler<BookEventArgs> BookReady;

    public void PublishNewBook(string bookTitle)

        if (BookReady != null)

            BookReady(this, new BookEventArgs(bookTitle));

Note that we have implemented a method PublishNewBook which when called raises the event. This makes sense since an event is always triggered after something has happened. In this case the publisher produces a new book and when it is ready he publicly announces this – he raises the event.

The BookEventArgs class used by the Publisher is given here

public class BookEventArgs : EventArgs

    public string BookTitle { get; set; }

    public BookEventArgs(string bookTitle)

        BookTitle = bookTitle;

Now the whole thing would be pretty useless if there weren’t interested readers or book stores around that react upon the event of the publisher, buy the book and read it. So lets implement a consumer of a book and call it the BookLover

public class BookLover

    public void ReadBook(string bookTitle)

        // some code

Most often the interested reader doesn’t go directly to the publish or is not directly connected with the publisher. The interested reader goes to a bookstore. The bookstore is the broker between a publisher and the readers. So let’s look at the code of the book store

public class Store

    public void MeetWithPublishers()

        var publisherX = new Publisher();

        publisherX.BookReady += OnNewBookReady;

        var titleForNewBook = "Introduction to Fluent Silverlight";

        publisherX.PublishNewBook(titleForNewBook);

    private void OnNewBookReady(object sender, BookEventArgs e)

        var personA = new BookLover();

        personA.ReadBook(e.BookTitle);

The book store organizes a meeting with the publisher (method MeetWithPublisher) and tells the publisher to produce a new book about fluent Silverlight. The store than registers itself with the publisher as a consumer of the BookReady event. Now whenever the book is ready the method OnNewBookReady is called by the publisher. In this method the store offers the book to its readers.

That’s a lot of code just to achieve one goal… we want to offer the book to an interested reader whenever it is available from the publisher. Can’t we reduce the code? Yes we can by using anonymous delegates. For a detailed introduction into anonymous delegates and lambda expressions please refer to this post.

public class Store

    public void OrganizeNextPublisherMeeting()

        var personA = new BookLover();

        var publisherX = new Publisher();

        var titleForNewBook = "Advanced usage of Fluent Silverlight";

        publisherX.BookReady += (sender, e) => personA.ReadBook(titleForNewBook);

In the above code snippet the action that is executed as a reaction on the event is defined as a lambda expression. By using this approach we don’t need to define an event handler method nor an extra EventArgs class and the code is much more compact.

Introducing Commands

Now let us generalize this whole thing a little bit. On one side we have a publisher of events. This can be any event e.g. the BookReady event in the sample above or the click event of a Silverlight command button. In the latter case the publisher would be the Silverlight control. On the other side we have some logic that we want to execute as a reaction to the event. We can also say that we want to “trigger an action” by the event. Let’s wrap the code that we want to execute (that is the action) into its own class. This class we call “a command”. Let’s start by defining an interface that all types of commands will implement

public interface IFsCommand<T>

    void Execute(T parameter);

The interface has a generic parameter T and thus is very flexible. The method Execute can be called with any type of parameter, be it a simple value type parameter or any reference type parameter, that is an instance of any type of class. We can then create a command class as follows

public class FsCommand<T> : IFsCommand<T>

    private readonly Action<T> action;

    public FsCommand(Action<T> action)

        this.action = action;

    public void Execute(T parameter)

        action(parameter);

This class expects an action with one parameter as parameter of the constructor. This action is executed whenever the method Execute of the command is called.

If we have a command button control and an instance of a command we can bind the click event of the button to this command like this

button.Click += (sender, e) => someCommand.Execute(someParameter);

Binding control events to commands defined in the view model

Imagine we have a Silverlight application with a view (i.e. UserControl) and a corresponding view model (see Model-View-ViewModel pattern – MVVM). The view contains a button which we want to bind to a command defined on the model. The model is defined as follows

public class Model

    public IFsCommand<int> SaveCustomerAction;

    public Model()

        SaveCustomerAction = new FsCommand<int>(p => OnSaveCustomer(p));

    private void OnSaveCustomer(int parameter)

        // logic to save the customer...

and the view is defined like this

public class View

    private Model model;

    public View(Model model)

        this.model = model;

        var saveCustomerButton = new FsButton();

        var parameter = 123;

        saveCustomerButton.Click += (sender, e) => model.SaveCustomerAction.Execute(parameter);

Each time that the click event of the saveCustomerButton is raised the action OnSaveCustomer is executed on the view model. It very important to notice that the action is defined on the view model rather than on the view. We have a clear separation of layout code/logic (the view) and presentation logic (the view model). This makes it easy to unit test the logic since it is completely decoupled from the view. In Silverlight a view cannot be tested in isolation thus it is very important to take out any logic of the view and put it into the model.

Availability and interactability of a command

A certain command can be available or not available depending on the context. This is a concept independent of a UI. But when a command is triggered by a visual element on a view then this availability can be represented by the visibility and/or interactability of the control. The availability of a command is usually governed by security requirements or the application or by the state in a workflow. Thus we’d rather set the availability of a command in the view model than in the view and we expect the bound controls to automatically set their state (visible and/or enabled) accordingly.

We can introduce a property IsExecuatble of type bool in the interface of our commands as well as an event IsExecutableChanged which is triggered whenever the value of the IsExecutable property changes.

public interface IFsCommand<T>

    void Execute(T parameter);

    bool IsExecutable { get; set; }

    event EventHandler IsExecutableChanged;

we can now change the code that binds the control to the command as follows

var action = model.SaveCustomerAction;

saveCustomerButton.Click += (sender, e) => action.Execute(parameter);

action.IsExecutableChanged += (sender, e) => saveCustomerButton.IsEnabled = action.IsExecutable;

// to initialze the button with the current value

saveCustomerButton.IsEnabled = action.IsExecutable;

From now on the button automatically updates its IsEnabled property whenever the property IsExecutable of the bound command changes.

We could now introduce a similar concept for the Visibility property of the control. How we do this depends on the specific context. In the applications we write at our company we have so called edit mode specifications which govern the interactability and visibility of commands or actions. These specification make a clear distinction between a command being visible but not interactable and a command not being visible at all. In this context we introduced the visibility as an extra property in the interface of the command analogous to the IsExecutable property. But your requirements may vary.

Our command class now looks like this

public class FsCommand<T> : IFsCommand<T>

    private readonly Action<T> action;

    private bool isExecutable;

    public FsCommand(Action<T> action)

        this.action = action;

    public void Execute(T parameter)

        action(parameter);

    public bool IsExecutable

        get { return isExecutable; }

set

            if(isExecutable == value) return;

            isExecutable = value;

            if (IsExecutableChanged != null)

                IsExecutableChanged(this, EventArgs.Empty);

    public event EventHandler IsExecutableChanged;

There remains one problem though. If our application is multi-threaded then the setter method of the IsExecutable property might cause troubles. Remember that the properties of any (Silverlight) control can only be accessed from the UI thread (usually the main thread). Thus if another thread trigger the change of the IsExecutable property of the command we will have a cross thread access exception. To avoid this scenario we thus have to synchronize threads. We can use the Dispatcher class of Silverlight to do so.

public bool IsExecutable

    get { return isExecutable; }

set

        if (isExecutable == value) return;

        isExecutable = value;

        OnIsExecutableChanged();

private void OnIsExecutableChanged()

    if (IsExecutableChanged == null) return;

    var dispatcher = DispatcherProvider.Dispatcher();

    if (dispatcher != null && !dispatcher.CheckAccess())

        dispatcher.BeginInvoke(OnIsExecutableChanged);

    else

        IsExecutableChanged(this, EventArgs.Empty);

Note that we use a DispatcherProvider to decouple the command from the framework and thus make unit testing possible. The DispatcherProvider just returns null in the context of a unit test. We defined the provider like this

public static class DispatcherProvider

    public static Func<Dispatcher> Dispatcher =

        () => Deployment.Current != null ? Deployment.Current.Dispatcher : null;

Now when unit testing a command we can simply configure the DispatcherProvider as follows

DispatcherProvider.Dispatcher = () => null;

In my next post I will continue with more details about binding control events to command/actions and will specifically discuss how we can weakly bind a control to an action. Stay tuned.

Fluent Silverlight – Table of content

Gabriel N. Schenker — Fri, 08 Jan 2010 13:54:47 GMT

In a series of posts I would like to introduce our Fluent Silverlight framework and discuss the important concepts behind it and describe some implementation details. This post will be updated continuously as I am adding new posts to the series

Table of content

The first three articles where I introduced the new framework as well as an article of Ray Houston about the technique we use for our view models to implement the INotifyPropertyChanged interface

and here are the post that discuss the more recent version of the interface

more to be published soon…

Fluent Silverlight – static reflection

Gabriel N. Schenker — Fri, 08 Jan 2010 13:29:31 GMT

Please view the table of content of this series for reference.

In my last post about binding dependency properties of a Silverlight control to a view model I used LINQ expressions to define the binding. I have written in the past about static reflection and the advantage of it versus dynamic reflection thus I do not want to repeat those arguments here. The main two reasons to use lambda expressions are

the binding can be defined in a strongly typed manner
the availability of meta information through the expression

When defining a data binding between a dependency property of a Silverlight control and a property on the view model we want to be able to use lambda expressions of the following type

simple member (property or field on the view model) access, e.g. m => m.Description
access of a nested member of of the view model, e.g. m => m.Name.Last
any of the above but with a type casting, e.g. m => (decimal)m.NumberOfItems

there might be other types of expressions that make sense in certain scenarios but we found that in our applications we only need the three types mentioned above. Given one or the other of the above expressions we need to extract the name (or path) to the corresponding member (property or field). We need this information to define the binding. Remember that the Binding class expects this information as parameter in the constructor; that is to define a binding to the property of name Description of the data context of the view (which will be the view model in our case) we use the following code

var binding = new Binding("Description");

and to define a binding to the nested property Last of the data context we would have the following code

var binding = new Binding("Name.Last");

If we use the debugger we can easily see that the NodeType of the expression body is MemberAccess for the first two expression types described above whereas it is Convert for the third type of expression.

In any case we want to get the –>MemberExpression “embedded” in the lambda expression. In the former case this is just the body of the lambda expression, thus

var memberExpression = expression.Body as MemberExpression;

and in the latter case a type cast operation is a so called unary expression an thus we can get to the interesting part (the member expression) via the code below

var body = (UnaryExpression)expression.Body;

var memberExpression = body.Operand as MemberExpression;

once we have extracted the member expression from our lambda expression we can use it to get access to the PropertyInfo (or FieldInfo if the member is a field – but we only use properties for data binding) via

var propertyInfo = (PropertyInfo)memberExpression.Member;

and from the PropertyInfo we can get the name (or path) of the corresponding property (of the model)

var path = propertyInfo.Name;

Wait a second, now this is not so easy for the nested property… there we effectively have a property chain. What we want is the path to the nested property to look like “Name.Last”. It turns out that we can just recursively iterate over a given member expression and extract the respective member to get a list of property info objects. This list of property info objects (in reverse order) can then be used to create the path.

Let’s first create this list of property info objects from the member expression

var list = new List<PropertyInfo>();

while (memberExpression != null)

    list.Add((PropertyInfo)memberExpression.Member);

    memberExpression = memberExpression.Expression as MemberExpression;

and now from this list we create the path

var path = string.Empty;

foreach (var info in list.Reverse())

    path += path Length > 0 ? "." + info.Name : info.Name;

That’s it; quite easy yet powerful isn’t it? Below I give the full code I use in my samples. To facilitate the whole thing a bit I introduced a SingleProperty and a PropertyChain class (both implement the interface Accessor). Their respective code is also given below. First I use an extension method GetAccessor for our lambda expressions

public static class ExpressionExtensions

    public static Accessor GetAccessor<TModel>(this Expression<Func<TModel, object>> self)

        var memberExpression = GetMemberExpression(self);

        return GetAccessor(memberExpression);

    private static MemberExpression GetMemberExpression<TModel, T>(Expression<Func<TModel, T>> expression)

        MemberExpression memberExpression = null;

        if (expression.Body.NodeType == ExpressionType.Convert)

            var body = (UnaryExpression)expression.Body;

            memberExpression = body.Operand as MemberExpression;

        else if (expression.Body.NodeType == ExpressionType.MemberAccess)

            memberExpression = expression.Body as MemberExpression;

        if (memberExpression == null) throw new ArgumentException("Not a member access", "expression");

        return memberExpression;

    private static Accessor GetAccessor(MemberExpression memberExpression)

        var list = new List<PropertyInfo>();

        while (memberExpression != null)

            list.Add((PropertyInfo)memberExpression.Member);

            memberExpression = memberExpression.Expression as MemberExpression;

        if (list.Count == 1)

            return new SingleProperty(list[0]);

        list.Reverse();

        return new PropertyChain(list.ToArray());

and here is the definition for the Accessor interface

public interface Accessor

    string Name { get; }

and the code for the SingleProperty class

public class SingleProperty : Accessor

    private readonly PropertyInfo propertyInfo;

    public SingleProperty(PropertyInfo property)

        propertyInfo = property;

    public string Name

        get { return propertyInfo.Name; }

and for the PropertyChain classes

public class PropertyChain : Accessor

    private readonly PropertyInfo[] chain;

    private readonly SingleProperty innerProperty;

    public PropertyChain(PropertyInfo[] properties)

        chain = new PropertyInfo[properties.Length - 1];

        for (var i = 0; i < chain.Length; i++)

            chain = properties;

        innerProperty = new SingleProperty(properties[properties.Length - 1]);

    public string Name

get

            var returnValue = string.Empty;

            foreach (var info in chain)

                returnValue += returnValue.Length > 0 ? "." + info.Name : info.Name;

            returnValue += returnValue.Length > 0 ? "." + innerProperty.Name : innerProperty.Name;

            return returnValue;

Enjoy

Fluent Silverlight – Binding dependency properties to model properties

Gabriel N. Schenker — Thu, 07 Jan 2010 13:47:33 GMT

Please view the table of content of this series for reference.

In my previous posts (here and here) I discussed how one can build a fluent API for the definition of objects. In the context of Fluent Silverlight these objects are Silverlight controls. With the aid of the expressions we want to define and instantiate controls. But we also want to show some data in the controls like text box, text block, combo box, etc. The data that we want to display is defined in what we call “view model”. We want to use data binding to achieve this goal.

Silverlight defines the necessary infrastructure for data binding that we want to use. To bind a dependency property of a control (e.g. the TextProperty of a text box) to a property of the data context of the view in which the textbox is defined we use the following code

var firstName = new TextBox{ Width = 100 };

var binding = new Binding("FirstName") {Mode = BindingMode.TwoWay};

firstName.SetBinding(TextBox.TextProperty, binding);

In the above sample we bind the text property of the textbox to the property named FirstName of the data context of the view. The binding is two way, that is if either side of the link is changed then the other side is automatically updated.

Now I’d prefer to have a fluent API to create textbox controls for me where I can express my intent to bind certain dependency properties to properties on the view model with the aid of lambda expressions. I want to have something like this

TextBox lastName = new TextBoxExpression<ViewModel>(m => m.LastName);

the result will be the same as in the first sample but the syntax is much cleaner and concise. We use a lambda expression m => m.LastName to define the binding in an intellisense-friendly and type-safe manner. The model is defined as

public class ViewModel

    public string LastName { get; set; }

and the expression itself is defined like this

public class TextBoxExpression<TModel>

    private Expression<Func<TModel, object>> textExpression;

    public TextBoxExpression(Expression<Func<TModel, object>> expressions)

        textExpression = expressions;

    protected virtual void BuildUp(TextBox element)

        var accessor = textExpression.GetAccessor();

        var binding = new Binding(accessor.Name);

        element.SetBinding(TextBox.TextProperty, binding);

    public static implicit operator TextBox(TextBoxExpression<TModel> expression)

        var element = new TextBox();

        expression.BuildUp(element);

        return element;

Please note that we use LINQ expressions and not just lambda functions to define the binding. This is necessary such as that we can use the meta data of the expression to define the binding. The method GetAccessor is an extension method for our LINQ expressions. The function uses the expression to retrieve important type information. The path for the binding is then just the name of the accessor returned by the extension method. I will talk more about this helper method in my next post.

We can add more methods to our fluent API to define bindings for more dependency properties. The usage will then be like this

TextBox lastName = new TextBoxExpression<ViewModel>(m => m.LastName)

                            .IsReadOnly(m => m.LastNameIsReadOnly)

                            .Visibility(m => m.LastNameVisibility);

the view model has two new properties

public class ViewModel

    public string LastName { get; set; }

    public bool LastNameIsReadOnly { get; set; }

    public Visibility LastNameVisibility { get; set; }

Remarks: the view model, as it is defined above cannot participate in a two-way data binding since it is not implementing the INotifyPropertyChanged interface. However this topic I will address in a subsequent post where I will show you how we provide our view model this necessary functionality in a AOP way.

The textbox expression contains these new and extended methods

public TextBoxExpression<TModel> IsReadOnly(Expression<Func<TModel, object>> expression)

    isReadOnlyExpression = expression;

    return this;

public TextBoxExpression<TModel> Visibility(Expression<Func<TModel, object>> expression)

    visibilityExpression = expression;

    return this;

protected virtual void BuildUp(TextBox element)

    var accessor = textExpression.GetAccessor();

    var binding = new Binding(accessor.Name);

    element.SetBinding(TextBox.TextProperty, binding);

    var accessor2 = isReadOnlyExpression.GetAccessor();

    var binding2 = new Binding(accessor2.Name);

    element.SetBinding(TextBox.IsReadOnlyProperty, binding2);

    var accessor3 = visibilityExpression.GetAccessor();

    var binding3 = new Binding(accessor3.Name);

    element.SetBinding(TextBox.VisibilityProperty, binding3);

One thing that should be evident is that in the BuildUp method we have a lot of repetitive code. It would be nice if we could simplify this code and make it more concise. Why not create a fluent API to define a binding? The result could be this

using (var binder = new PropertyBinder<TModel>(element))

    binder.DependencyProperty(TextBox.TextProperty).BindTo(textExpression).Mode(BindingMode.TwoWay);

    binder.DependencyProperty(TextBox.IsReadOnlyProperty).BindTo(isReadOnlyExpression);

    binder.DependencyProperty(TextBox.VisibilityProperty).BindTo(visibilityExpression);

again a step in the right direction towards better readability! The definition of this new fluent API is shown below.

public class PropertyBinder<TModel> : IPropertyBinderExpression<TModel>, IDisposable

    private bool elementHasBeenBound;

    private readonly FrameworkElement element;

    private BindingInfo current;

    private readonly List<BindingInfo> bindingInfos;

    public PropertyBinder(FrameworkElement element)

        this.element = element;

        bindingInfos = new List<BindingInfo>();

    public IPropertyBinderExpression<TModel> DependencyProperty(DependencyProperty dp)

        current = new BindingInfo { DependencyProperty = dp };

        bindingInfos.Add(current);

        return this;

    IPropertyBinderExpression<TModel> IPropertyBinderExpression<TModel>.BindTo(Expression<Func<TModel, object>> expression)

        current.Expression = expression;

        return this;

    IPropertyBinderExpression<TModel> IPropertyBinderExpression<TModel>.Mode(BindingMode mode)

        current.Mode = mode;

        return this;

    public void Bind()

        if(elementHasBeenBound)

            throw new InvalidOperationException("Binding for this control has already been setup.");

        foreach (var info in bindingInfos)

            var binding = new Binding(info.Expression.GetAccessor().Name);

            if (info.Mode.HasValue) binding.Mode = info.Mode.Value;

            element.SetBinding(info.DependencyProperty, binding);

        elementHasBeenBound = true;

    public void Dispose()

        Bind();

    private class BindingInfo

        public DependencyProperty DependencyProperty;

        public Expression<Func<TModel, object>> Expression;

        public BindingMode? Mode { get; set; }

and the interface implemented by the above class is

public interface IPropertyBinderExpression<TModel>

    IPropertyBinderExpression<TModel> BindTo(Expression<Func<TModel, object>> expression);

    IPropertyBinderExpression<TModel> Mode(BindingMode mode);

To be able to use the nice using-syntax the property binder class implements the IDisposable interface. The implementation of the Dispose method then just calls the Bind method of the class. In the Bind method the whole bindings are executed. This method has been guarded such as that it can only be called once otherwise an exception is thrown.

Note that in my private class BindingInfo I have defined the field Mode as BindingMode? and NOT as BindingMode. This makes it easy for me to detect whether the user has set the binding mode or not when defining the binding for a dependency property.

Now if we need more functionality regarding binding we can just extend our fluent API, that is our property binder class. One scenario that comes to mind is the usage of value converters. For this case we can just add another method to the fluent API

public IPropertyBinderExpression<TModel> WithValueConverter<TConverter>()

    where TConverter : IValueConverter, new()

    current.ValueConverter = new TConverter();

    return this;

the BindingInfo class has an additional field

public IValueConverter ValueConverter;

and the Bind method contains this additional statement

if (info.ValueConverter != null) binding.Converter = info.ValueConverter;

In my next post I will explain the code we use to extract the needed meta information from a given lambda expression.

Silverlight and styles

Gabriel N. Schenker — Wed, 06 Jan 2010 13:43:40 GMT

This post is the result of a couple of frustrating moments passed yesterday. In our application we use the date picker control of the Silverlight toolkit. Unfortunately this control does not work exactly as we would like to thus I decided to redefine its template such as that the control better fits our needs. I didn’t want to put the new style into the app.xaml file but rather store it as a resource in the assembly where our new and improved date picker resides.

The generic.xaml

The documentation about how this is to be done is incomplete at best. After Google-ing I quickly found out that we can put the styles in a file called generic.xaml; e.g. something like this

<ResourceDictionary

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    xmlns:controls="clr-namespace:MyNamespace"

    <Style TargetType="controls:SampleButton">

        <Setter Property="BorderThickness" Value="1" />

        <Setter Property="Template">

            <Setter.Value>

                <ControlTemplate TargetType="controls:SampleButton">

                    <Border CornerRadius="2"

                            BorderThickness="{TemplateBinding BorderThickness}">

                        <ContentPresenter/>

                    </Border>

                </ControlTemplate>

            </Setter.Value>

        </Setter>

    </Style>

</ResourceDictionary>

Note that the above is just a sample style that I used to experiment with. The style for the date picker is much more complex.

In the constructor of my sample control I then just have to put this assignment

public SampleButton()

    DefaultStyleKey = typeof(SampleButton);

Ok, nice, so did I. But my application didn’t work any more; the style was not picked up as before (when it was defined in the app.xaml). After some more Google-ing I found out that the Build Action of the generic.xaml has to be of type Resource. Still no success. My custom control did not pick up the style.

Still more Google-ing was needed and some consumption of videos on the official Silverlight site. The next piece of information I got was that the generic.xaml file has to reside in a folder called Themes. Hurray, finally my custom control worked.

Merging resources

Well, now if we have many custom controls with many different styles and other resources the generic.xaml file quickly gets crowded too. Luckily there exists a possibility how one can merge the generic.xaml from different sources. Thus I can define my styles for different controls in individual resource files. The syntax for this is

<ResourceDictionary

    xmlns="http://schemas.microsoft.com/client/2007"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

    <ResourceDictionary.MergedDictionaries>

        <ResourceDictionary Source="/FluentSilverlight;component/Themes/FsDatePicker.xaml"/>

        <ResourceDictionary Source="/FluentSilverlight;component/Themes/FsComboBox.xaml"/>

    </ResourceDictionary.MergedDictionaries>

</ResourceDictionary>

It is very important to note that there is an inconsistency in the way merge dictionaries are defined in the app.xaml and in the generic.xaml. Where in the former case the attribute Source of the tag ResourceDictionary is a relative URI in the latter Source must be an absolute URI and has the following structure

<ResourceDictionary Source="/assemblyName;component/path/fileName.xaml">

Where assemblyName is the name of the assembly where the xaml file is contained; component is a keyword; path is the path to the file and fileName is the name of the xaml file to merge. So in the above sample the assembly is FluentSilverlight and the two xaml files reside in a folder inside the project called Themes

Meaningful Exception text anybody?

One of the most annoying factors with Silverlight is that its exception texts are often pretty useless. If there is a mistake in the definition of a template you get a very cryptic error message. Some more love from Microsoft regarding exceptions would be highly appreciated.

Fluent Silverlight – Fluent API and inheritance

Gabriel N. Schenker — Sun, 03 Jan 2010 21:09:04 GMT

Please view the table of content of this series for reference.

Introduction

In my last post I showed how we can implement a fluent API to help us construct instances of specific classes. When using a fluent API the code is in general much more readable. In this post I want to go one step further and show how we can implement a hierarchical fluent API.

Defining a base expression

Our objects that we use in our applications are often inherited from some base class as in the following simple example.

Here we have an abstract Person base class from which the Employee class inherits. We might have another class e.g. Customer that also inherits from Person. If we now want to implement a fluent API for the construction of Employee- and/or Customer objects then it makes sense that our fluent API is also hierarchically organized. We might want to build a parallel hierarchy of PersonExpression, EmployeeExpression and CustomerExpression where the latter two inherit from the first expression.

But now we have a problem. From my previous article we know that each method in a fluent API has to return the expression itself. But if we now implement say the LastName() method in the PersonExpression like this

public abstract class PersonExpression

    private string lastName;

...

    public PersonExpression LastName(string value)

        lastName = value;

        return thisInstance();

...

then when used in the context of an EmployeeExpression (where EmployeeExpression inherits from PersonExpression)

Employee john = new EmployeeExpression()

    .FirstName("John")

    .LastName("Doe")

...

we will not be able to get to any of the members defined in the EmployeeExpression any more since our continuation is of type PersonExpression and NOT of type EmployeeExpression. With other words: whenever we use a method of the base expression in our fluent expression then we loose the context!

Thus we have to find another solution. The solution is to introduce a generic parameter which will be used as the type of the return value of the methods of our expression classes. Consequently we will write

public abstract class PersonExpression<THIS>

    where THIS : PersonExpression<THIS>

    private string lastName;

...

    public THIS LastName(string value)

        lastName = value;

        return thisInstance();

...

If we use the generic parameter THIS instead of a concrete (base) expression, then we will never loose the context. Please note also that the LastName method does not return ‘this’ any more but rather the return value of the function thisInstance which is defined as follows

protected THIS thisInstance()

    return (THIS)this;

So we never should return directly this any more in our expression hierarchy but rather thisInstance().

But wait, we have still one more problem: since we want to define the implicit type conversion in the base class we also have to introduce the target type as a generic parameter such as that we can then write

public static implicit operator TARGET(PersonExpression<THIS, TARGET> expression)

    var target = new TARGET();

    expression.BuildUp(target);

    return target;

where the BuildUp function is defined as follows

protected virtual void BuildUp(TARGET target)

...

this method will be overriden by the child expressions to build-up the target object.

The full code for the PersonExpression will now look like this

public abstract class PersonExpression<THIS, TARGET>

    where THIS : PersonExpression<THIS, TARGET>

    where TARGET : Person, new()

    private string lastName;

    private string firstName;

    private DateTime dateOfBirth;

    private Gender gender;

    public THIS LastName(string value)

        lastName = value;

        return thisInstance();

    public THIS FirstName(string value)

        firstName = value;

        return thisInstance();

    public THIS DateOfBirth(DateTime value)

        dateOfBirth = value;

        return thisInstance();

    public GenderExpression<PersonExpression<THIS, TARGET>> Gender

        get{ return new GenderExpression<PersonExpression<THIS, TARGET>>(this, x => gender = x);}

    protected THIS thisInstance()

        return (THIS)this;

    protected virtual void BuildUp(TARGET target)

        target.LastName = lastName;

        target.FirstName = firstName;

        target.DateOfBirth = dateOfBirth;

        target.Gender = gender;

    public static implicit operator TARGET(PersonExpression<THIS, TARGET> expression)

        var target = new TARGET();

        expression.BuildUp(target);

        return target;

Note how the two generic parameters are restricted by their respective where filters. This restriction is very important to make the whole concept work.

The full code for the EmployeeExpression is given below

public class EmployeeExpression : PersonExpression<EmployeeExpression, Employee>

    private DateTime hireDate;

    private decimal yearlySalary;

    public EmployeeExpression HireDate(DateTime value)

        hireDate = value;

        return thisInstance();

    public EmployeeExpression YearlySalary(decimal value)

        yearlySalary = value;

        return thisInstance();

    protected override void BuildUp(Employee target)

        base.BuildUp(target);

        target.HireDate = hireDate;

        target.YearlySalary = yearlySalary;

and the expression can now be used in the following way

Employee john = new EmployeeExpression()

    .FirstName("John")

    .LastName("Doe")

    .DateOfBirth(new DateTime(1964, 4, 14))

    .HireDate(new DateTime(2007, 3, 1))

    .YearlySalary(90000);

With the aid of some “generics magic” we are now able to implement a hierarchically structured fluent API for our objects we want to construct. This is a very important pattern we used when implementing Fluent Silverlight.

Fluent Silverlight – Implementing a fluent API

Gabriel N. Schenker — Sat, 02 Jan 2010 10:04:00 GMT

Please view the table of content of this series for reference.

Introduction

Quite some time has passed since we published our Fluent Silverlight framework. In the mean time we have been very busy extending the framework and using it in our internal products. Unfortunately we have been so busy that there was no time left to publish the extension we made.

Never the less there has been some interest in this framework lately such as that I decided to finally take a spin an bring the current version that we use internally in our company to a level where I can publish it. The updated framework will be published shortly.

Since code alone does not always show the possibilities how to use it I want to second it with a series of short articles.

A fluent API

A good description on what a fluent API is can be found here. Generally spoken a fluent API makes the code more readable.

In our context we can identify four different categories that we want to define via the fluent interface.

basic property values like strings, numbers, boolean values, dates, etc.
enum type values like Visibility, HorizontalAlignment, BindingMode, etc.
binding dependency properties to properties of the view model
binding events to commands on the view model

Let me show a simple sample of a fluent API which incorporates the first two categories mentioned above.

Car car = new CarExpression()

    .Make("Kia Sorento")

    .ListPrice(22500)

    .Type.SUV()

    .Build();

First I create an instance of type CarExpression. Then I define the make and list price of the car which are standard properties of type string and decimal respectively. Next I define the type of the car which is an enum. Finally I tell the CarExpression to build the car with the given settings. The definition of the Car class is just

public class Car

    public string Make { get; set; }

    public decimal ListPrice { get; set; }

    public CarTypes Type { get; set; }

and the CarTypes enum is defined as follows

public enum CarTypes

    SportsCar, SUV, MiniVan, Sedan

having defined these two types I can then start implementing the CarExpression as shown below

public class CarExpression

    private string make;

    private decimal listPrice;

    private CarTypes carType;

    public CarExpression Make(string value)

        make = value;

        return this;

    public CarExpression ListPrice(decimal value)

        listPrice = value;

        return this;

We can see that for each property of the car that I want to define via the fluent API I have defined an internal field in the CarExpression. For normal properties like Make the definition of the corresponding method in the fluent API is simple. It’s always a method which returns an object of type CarExpression. Thus we will always have a return this; statement at the end of the method. Other than that the method just stores the passed in parameter value in the corresponding internal field for future use.

It is the fact that the methods are always returning “this” makes it possible to have a fluent interface.

Enum type properties are a little bit more involved. We have to implement an expression on its own for each enum we want to use in our fluent API. Let me show the code used for the CarTypes enum

public class CarTypeExpression<TParent>

    private readonly TParent parentExpression;

    private readonly Action<CarTypes> action;

    public CarTypeExpression(TParent parentExpression, Action<CarTypes> action)

        this.parentExpression = parentExpression;

        this.action = action;

    public TParent SportsCar()

        action(CarTypes.SportsCar);

        return parentExpression;

    public TParent SUV()

        action(CarTypes.SUV);

        return parentExpression;

    public TParent Sedan()

        action(CarTypes.Sedan);

        return parentExpression;

    public TParent MiniVan()

        action(CarTypes.MiniVan);

        return parentExpression;

The points to mention are that the expression is generic. The generic parameter TParent will correspond to the expression in which context this enum expression is going to be used. In our simple sample this will be the CarExpression. The other point to mention is the constructor. The constructor expects 2 parameters, the first being the parent expression inside which this enum expression is used and the second parameter is the action that shall be executed by this enum expression whenever one of its methods is used. The enum expression is only a helper expression and thus must not store any values internally but rather pass selected values back to the parent expression. That is the reason why we have to define this action.

Now let’s have a look a one of those methods of the enum expression. In the first line we use the action mentioned above and pass as a parameter the correct enum value. Then we return the parent expression instance. This is very important! We want to continue working with the car expression once we have selected a car type. If we would instead return “this” then we could only select other types which makes absolutely no sense…

The reason why we have chosen the enum expression to be generic in TParent is that we might want to use an enum expression in different contexts, that is inside different parent expressions. If we are 100% sure that we are only going to use an enum expression inside a single type of expression then we could simplify the above enum expression and make it non-generic.

So let’s now show the missing parts of the car expression

public class CarExpression

...

    public CarTypeExpression<CarExpression> Type

        get{ return new CarTypeExpression<CarExpression>(this, x => carType = x);}

    public Car Build()

        return new Car {Make = make, ListPrice = listPrice, Type = carType};

As you will notice we have implemented the Type as a readonly property and not as a method. Please also note the lamda expression which defines the action we pass to the enum expression

x => carType = x

This lambda expression tells the system to take the parameter that the respective method in the enum expression will pass to the action and assign its value to the field carType of the car expression.

What I do not like in my fluent API that I have defined so far is the fact that I have to call a Build method to tell the expression to build an instance of a car. That seems something unnecessary to me… How can I let the expression know that I want to have my car built without explicitly telling it? Well if I don’t want to tell it explicitly then I have to tell it implicitly. What means do I have to tell something implicitly? Oh yes, i can use operator overloading to define an implicit type cast operation.

Whenever I assign an object of type CarExpression to a variable of type Car the system tries to do an implicit type conversion. If no such conversion is defined the system will throw a TypeCastException. But we can define such an implicit type conversion. In our sample the code needed looks like this

public static implicit operator Car(CarExpression expression)

    return new Car

                   Make = expression.make,

                   ListPrice = expression.listPrice,

                   Type = expression.carType

};

We can now update our usage of the expression like shown below

Car car = new CarExpression()

    .Make("Kia Sorento")

    .ListPrice(22500)

    .Type.SUV();

This is much more natural than explicitly calling some Build method.

Writing a profiler for Silverlight applications – Part 2

Gabriel N. Schenker — Tue, 08 Dec 2009 13:31:29 GMT

Introduction

Unfortunately there doesn’t yet exist any decent profiler for Silverlight applications. This fact inspired me to write my own profiler which is able to profile any member of any assembly of our solution and help me track down performance bottlenecks and other potential problems of our applications.

In part one of this post series I showed how we can use Mono Cecil to instrument any (compiled) assembly and thus prepare it for being profiled. In this second part I want to discuss what data we collect as well as how we collect the data. And finally we show a way how to dump the data generated by the profiler to a pre-defined output where it can be used for further analysis. The analysis part of the profiler I will discuss in part 3 of the post series.

What data to collect

Instrumenting an assembly is one thing but the other important thing is to collect meaningful data. Profiling is all about how the application behaves during run time and how the various operations perform.

Each application has a well defined single entry point which is called by the assembly loader upon start of the application. Starting from this entry point or start method other methods are called which in turn call again other methods. In the end we have a tree of calls. Thus our data structure must also be a tree structure.

I have defined a class Call which contains all data I want to collect for a single node of my call tree. Each call has a unique id and a collection of child nodes of type Call. For easier navigation I also provide a backward link to the parent of each call that is to its caller.

For each method(or call) I register the total time spent inside this method as well as the type in which this method is defined and the meta information of the current method. I also register the number of times a method is called by its parent.

Certainly there might be other interesting data to collect, but for our purposes this was enough.

Running the instrumented application

Please be aware that a fully instrumented application produces a huge amount of profiling data. In our case running the application for only a couple of seconds produced several 10 thousands of nodes. Also be aware that profiling an application has a significant impact on its performance. I strongly advise that you do not use this profiler or this technique in production but only on your developer machine or on a test system.

Intercepting the method calls

In the first part of this post series I have shown how we can instrument any assembly with the aid of Mono Cecil such as that any method call in the respective assembly can be intercepted. In our case I just inserted a call to an external profiler class at the beginning and at the end of each method.

The code inserted at the beginning of each method was

ProfileInfoTracker.WhenEnteringMethod();

and the one at the end

ProfileInfoTracker.WhenLeavingMethod();

Let’s now analyzed the code inside those methods. First the WhenEnteringMethod

public static void WhenEnteringMethod()

    var timeIn = DateTime.Now;

    var method = GetCallingMethod();

    var parentCall = Stack.Count > 0 ? Stack.Peek() : RootCall;

    Call call = null;

    if (parentCall.Children.ContainsKey(method))

        call = parentCall.Children[method];

    else

        call = new Call

                       Type = method.ReflectedType,

                       Method = method,

};

        parentCall.Children.Add(method, call);

    call.NumberOfCalls++;

    call.SetEnterTime(timeIn);

    Stack.Push(call);

As the very first operation we save the current time and then we determine the MethodBase (meta information) of the method that called us. We use the StackFrame class to provide us this information.

private static MethodBase GetCallingMethod()

    var StackFrame = new StackTrace();

    return StackFrame.GetFrame(2).GetMethod();

By using our internal stack we are now able to retrieve the caller of the intercepted method. We call this the parent call. If there is no call on the stack we are obviously at the very beginning of the call chain and thus we return the root call object.

Now it is possible that the parent call calls another method more than once. If so then its children collection would already contain this call and thus we have to use it. Otherwise we create a new call object and store it in the parent calls children collection. When defining a new call object we provide it the MethodBase object as well as the Type in which the method is defined. We also increase the number of calls to this specific method and set the recorded enter time. Finally we push the call object onto our stack.

The second method is rather trivial

public static void WhenLeavingMethod()

    var call = Stack.Pop();

    call.SetLeaveTime(DateTime.Now);

we just pop the current call from the stack and feed it with the current time which defines the method exit time. That’s all!

Multi threaded applications

Unfortunately we are not done yet. There is one little call in the above code that hides some complexity. It is the RootCall and the Stack property. The logic inside the property getter is

public static Call RootCall

get

        if(rootCall == null) rootCall = new Call();

        return rootCall;

for the root call and for the stack it is

private static Stack<Call> Stack

get

        if(stack == null)

            stack = new Stack<Call>();

        return stack;

As you can see these are just two lazy instantiated properties but in this case it is important since we deal with a multi threaded application. We define the rootCall field as follows

[ThreadStatic]

private static Call rootCall;

in a similar way we define our internal stack

[ThreadStatic]

private static Stack<Call> stack;

Please note the [ThreadStatic] attribute on the two fields. This attribute guarantees us that we collect the data for each thread separately. The attribute defines that the corresponding static fields are not globally static but only static per thread. In a subsequent part of this series I will discuss the code modifications needed to retrieve the profiling data for all threads. At the moment we are only interested in the profiling data of the main thread (i.e. the UI thread).

Retrieving the profiling data

In a Silverlight application the possibility to store data in the file system of the client are rather limited. This is by design due to security reasons. In our case we decided to provide a special key combination to the Silverlight client which will then dump the profiling data as an xml document to a textbox in a popup dialog. From there we can copy the output to any text editor (e.g. Notepad++), manipulate it if needed and save it to the file system.

In the startup event handler we attach the Silverlight Profiler to the key down event of the root visual

private void Application_Startup(object sender, StartupEventArgs e)

...

  RootVisual.KeyDown += (s,e) => SilverlightProfiler.OnKeyDown(s, e);

...

The OnKeyDown method contains the following code

public static void OnKeyDown(object sender, KeyEventArgs e)

    if (e.Key == Key.Y && CtrlPressed() && ShiftPressed())

        ProfileInfoTracker.ToggleProfilingOnOff();

    else if (e.Key == Key.Z && CtrlPressed() && ShiftPressed())

        var sb = new StringBuilder();

        var writer = new StringWriter(sb);

        ProfileInfoTracker.DumpProfile(writer);

        HandleOutput(sb.ToString());

With the key combination CTRL-SHIFT-Y we can start and stop profiling whereas with the combination CTRL-SHIFT-Z we can dump the profiler output to the defined output.

The HandleOutput method opens a modal dialog which contains a textbox into which we write the profiler output.

private static void HandleOutput(string output)

    var modalDialog = new ModalDialog();

    modalDialog.Show(output);

The custom designed ModalDialog class is using the Popup class of Silverlight to display a dialog like window on top of the browser.

Summary

In our company we have implemented a Silverlight profiler to be able to track performance bottlenecks and other potential problems in our solution. In part two of this post series I have show you what data we collect with our profiler and how we collect this data. Furthermore I have discussed a possible way to extract the profiling data for further use in a analysis tool which I will discuss in part three of this series.

Writing a profiler for Silverlight applications – Part 1

Gabriel N. Schenker — Thu, 26 Nov 2009 19:42:28 GMT

In this article I want to discuss the steps needed to instrument a Silverlight assembly such as that it can be profiled. To achieve this task I use Mono Cecil, a library from the Mono platform which is an open source implementation of .NET.

Introduction

In my company we have a very complex Silverlight application. This application is highly dynamic and fully asynchronous. Lately we encountered some performance problems on slower PCs. Unfortunately there doesn’t yet exist any decent profiler for Silverlight applications. Since - as I already mentioned - our application is rather complex it is difficult to impossible to analyze this application thoroughly without a good profiling tool. We have tried various ways to track down the problems by e.g. manually adding trace code or by writing profiling interceptors for all our classes that are registered in the IoC container. With this methods we were able to track some hotspots but these were only the tips of an iceberg.

While discussing with a coworker who showed me what he is doing with the aid of the Mono Cecil library I suddenly realized: “I can write my own profiler!”.

This is my first project using the Mono Cecil library. In this project we only need the Mono.Cecil.dll assembly.

Please note that the techniques presented here can be used for any type of assembly and are not restricted to Silverlight assemblies.

First Step – discovering all types and its members

I want visit all members of all my types in the assembly that I want to instrument for profiling purposes. The first code snippet I use to test my intent is

public void Parse(Assembly assembly)

    var assemblyDef = AssemblyFactory.GetAssembly(assembly.Location);

    Console.WriteLine("Assembly {0}", assemblyDef.Name);

    foreach (TypeDefinition type in assemblyDef.MainModule.Types)

        if (type.Name == "<Module>") continue;

        Console.WriteLine("Type {0}", type.Name);

        foreach (MethodDefinition method in type.Methods)

            Console.WriteLine("Method {0}", method.Name);

The above code uses the Mono.Cecil assembly and just prints all members of all types of the assembly passed as a parameter to the method. I specifically want to verify that even private methods and automatic properties are discovered correctly. Please note that a property is nothing else than a pair of a setter and a getter method. The type I am analyzing is defined as follows

public class TestClass
{
    public TestClass()
    {
        Console.WriteLine("Constructor of TestClass");
    }

    public void PublicVoidFunction()
    {
        
    }

    protected int ProtectedIntFunction()
    {
        return 0;
    }

    private decimal PrivateDecimalFunction()
    {
        return 1.0m;
    }

    public string AutomaticProperty { get; set; }

    private string standardProperty;
    public string StandardProperty
    {
        get { return standardProperty; }
        set { standardProperty = value; }
    }
}

and the output generated is

We can immediately see that everything is listed as expected except for the constructor. How can I get hold on the constructor? It turns out that the type definition does have a constructors collection which provides me exactly the information needed

foreach (MethodDefinition method in type.Constructors)
{
    Console.WriteLine("Constructor {0}", method);
}

Now it will be interesting to know if I can also discover anonymous functions since we use them very intensively in our code base. It is thus absolutely mandatory to also instrument those functions. And it turns out that Cecil indeed discovers them. If I have the following method call

MethodWithAFunctionParameter(i =>
                                 {
                                     var random = new Random((int) DateTime.Now.Ticks);
                                     return i < random.Next(100);
                                 });

This anonymous function is discovered and output as follows

The first part of the name <PublicVoidFunction> is taken from the method that contains the anonymous function definition.

Second step – Injecting instrumentation code

Ok, now I have everything to start with my instrumentation. This will be the harder part since I have to inject some code into every discovered method. The code has to be in MSIL. I will have some code at the beginning of each method and some at the end of each method. I will call the former pre-invocation code and the latter post-invocation code.

To avoid any unnecessary complexity my pre- and post-invocation code should be as simple as possible. Thus I decided to just make a parameter less call to a (static) method of a specific class. This class will contain all logic needed to profile my application. In my sample I call this class ProfileInfoTracker and the static methods I want to call are WhenEnteringMethod and WhenLeavingMethod.

Thus each instrumented method of my assembly will look like this void sample function

public void PublicVoidFunction()

    ProfileInfoTracker.WhenEnteringMethod();

    // user code...

    ProfileInfoTracker.WhenLeavingMethod();

or this function returning a result

protected int ProtectedIntFunction()

    ProfileInfoTracker.WhenEnteringMethod();

    // user code...

    // ...

    result = ...

    ProfileInfoTracker.WhenLeavingMethod();

    return result;

Before fumbling around with IL code I implemented a reference method including the pre- and post-invocation code in C# and compiled it. Then I analyzed the output in Reflector.

This is the method I analyzed in C#

public void PublicVoidFunction()

    ProfileInfoTracker.WhenEnteringMethod();

    Random random = new Random((int) DateTime.Now.Ticks);

    Thread.Sleep(random.Next(50));

    ProfileInfoTracker.WhenLeavingMethod();

and this is the very same method in IL code

.method public hidebysig instance void PublicVoidFunction() cil managed

    .maxstack 3

    .locals init (

        [0] class [mscorlib]System.Random random,

        [1] valuetype [mscorlib]System.DateTime time)

    L_0000: call void Instrumenter.ProfileInfoTracker::WhenEnteringMethod()

    L_0005: nop

    L_0006: call valuetype [mscorlib]System.DateTime [mscorlib]System.DateTime::get_Now()

    L_000b: stloc.1

    L_000c: ldloca.s time

    L_000e: call instance int64 [mscorlib]System.DateTime::get_Ticks()

    L_0013: conv.i4

    L_0014: newobj instance void [mscorlib]System.Random::.ctor(int32)

    L_0019: stloc.0

    L_001a: ldloc.0

    L_001b: ldc.i4.s 50

    L_001d: callvirt instance int32 [mscorlib]System.Random::Next(int32)

    L_0022: call void [mscorlib]System.Threading.Thread::Sleep(int32)

    L_0027: nop

    L_0028: call void Instrumenter.ProfileInfoTracker::WhenLeavingMethod()

    L_002d: ret

The interesting parts for me are the two lines at L_0000 and L_0028. I will have to use Mono Cecil to inject those statements in each and every method of the assembly I want to instrument.

It turns out that there is a very limited amount of documentation available for Mono Cecil. This made my start a little bit slow. But after I waded through those upfront difficulties the usage is straight forward.

I can create such an IL call instruction with the following code

private Instruction CreateCallInstruction(CilWorker worker, string methodName)

    var methodInfo = typeof(ProfileInfoTracker).GetMethod(methodName);

    var methodReference = assembly.MainModule.Import(methodInfo);

    return worker.Create(OpCodes.Call, methodReference);

the above method has two parameters. The first one is the CIL worker object which I can get for via the MethodReference of the method I am currently instrumenting

var worker = methodReference.Body.CilWorker;

The second parameter is the name of the method I want to call on the target class which in our case is just the ProfileInfoTracker class.

With the aid of the CIL worker I can the create my desired IL call instruction (the WhenEnteringMethod and well as the WhenLeavingMethod call).

To instrument the current method I can now use the following code

private void InstrumentMethod(MethodDefinition method)

    AddPreInvocationCode(method);

    AddPostInvocationCode(method);

private void AddPreInvocationCode(MethodDefinition method)

    var worker = method.Body.CilWorker;

    var callMethod = CreateCallInstruction(worker, "WhenEnteringMethod");

    var lastInstruction = method.Body.Instructions[0];

    worker.InsertBefore(lastInstruction, callMethod);

private void AddPostInvocationCode(MethodDefinition method)

    var worker = method.Body.CilWorker;

    var callMethod = CreateCallInstruction(worker, "WhenLeavingMethod");

    var lastInstruction = method.Body.Instructions[method.Body.Instructions.Count - 1];

    worker.InsertBefore(lastInstruction, callMethod);

    ReplaceJumpToLastInstructionWithJumpToPostInvocationCall(method, lastInstruction, callMethod);

Note that the pre-invocation call is added as very first instruction of the method boy whereas the post-invocation call instruction is added as second-last instruction; right before the “ret” OpCode.

Also not the call to the method ReplaceJumpToLastInstructionWithJumpToPostInvocationCall. If inside the method (previous to instrumenting it) there is a jump to the last op code (the ret statement) we have to replace this jump with a jump to our post-invocation call. This can be achieved like this

private void ReplaceJumpToLastInstructionWithJumpToPostInvocationCall(MethodDefinition method, Instruction lastInstruction, Instruction callMethod)

    var jumpInstructions = method.Body.Instructions.Cast<Instruction>()

        .Where(i => i.Operand == lastInstruction);

    jumpInstructions.ForEach(i => i.Operand = callMethod);

Summary

In this article I have discussed how the Mono Cecil library can be used to instrument an existing .NET assembly and make it ready to be profiled. In the next post I will discuss the gathering and analysis of profiling data.