Today is a big day for Catel. The first official beta for version 3.0 has just been released!

Where to get it?

There are two ways of getting the latest release.

1) Download the setup package here, it will install the templates, code snippets, assemblies and docs (recommended)

2) Get the latest pre-release packages via NuGet

What to expect?

Recently, I wrote a blog post of what is coming in the new Catel 3.0 release. However, is is a short summary:

• New assemblies that are now the same for all target frameworks
• Non-generic views
• ViewModelLocator and ViewLocator
• FluentValidation extensions (available as a separate extension)
• and much more improvements!

Where are the new docs?

The latest documentation ships with the setup package as CHM file. However, you can also view the latest documentation here:

http://catel.catenalogic.com/3.0-beta/

How to convert my current Catel application to 3.0?

We have written a guide which should explain all the stuff that you might walk into. If you feel that the guide is not up-to-date or incomplete, please let us know. You can find the guide here:

http://catel.catenalogic.com/3.0-beta/index.html?whats_new_in_catel_3_0.htm

Where to report issues or feature requests?

We would love to hear from you. If you have any bugs, feature requests or whatsoever, please let us know in the discussion forums.

Lots of people are very excited with Catel, but are somehow afraid that it will not perform because so much is possible and done automatically for you. Recently, we got a free license of the ANTS Performance Profiler for the efforts we put into Catel. We really appreciate it, and want to share our experience with profiling the performance.

Profiling the examples

The first thing we did was to profile the example applications. However, we couldn’t find any performance issues in the examples (even the larger ones). But, we have a work item to tackle the top 10 % most expensive calls, how to do that when all performance very well?

Well, we have a very large coverage of unit tests, so maybe we can profile these?

Profiling the unit tests

Now it really gets cool. I got the idea to profile our unit tests since it covers most of the (non-UI) API calls, so it would be a very good way to find the top 10 % worst performing methods. Then I stumbled upon this article. It tells in detail how to profile the performance using MSTest. How cool is that!

We use the following configuration to profile our unit tests:

After setting up the configuration, we only had to wait until all 1300 unit tests completed. I must admit it takes a while to run and analyze the results (appr. 5 minutes), but that’s a good time to get a cup of coffee. When we returned, we could select the part with the most red stuff and select it in the graph:

As we know, the binary redirect-serializer of Catel is the most expensive one (it allows you to change type names and assemblies when using binary serialization). It only costs much performance when the type system has actually changed, which happens in a “Convert to new format” wizard or something like that.

Anyway, it is very cool that we can now decide whether we want to put effort into this method and focus on what is really important for the users of Catel. For example, a validation sequence that takes 50 ms (that runs 5 times a second) has a higher priority than a once in a namespace changing redirect-serializer.

Conclusion

There are actually two conclusions:

1. ANTS Performance Profiler rocks! How cool is it that when you cover everything using unit tests, you don’t need to test anything with a UI, but can simply run the unit tests. Maybe we can even integrate it into our continuous integration build and e-mail the top 10 % worst performing methods.
2. While writing Catel, the team did an excellent job in keeping the performance in mind. We couldn’t find any real performance bottlenecks, so actually we are very, very happy with the results

Last month, the development team of Catel has been working very hard to provide a brand new release of Catel, namely 3.0.

We decided to jump from 2.5 to 3.0 because this gave us the opportunity to introduce breaking changes. We hate to introduce breaking changes, but we have added all changes into this release so you only have to go through the breaking changes once.

This blog posts covers the most important changes to Catel 3.0, and why you should definitely upgrade as soon as it becomes available.

New assemblies

All versions before Catel 3.0 had different assembly names for WPF, Silverlight and WP7. We have now created exactly the same libraries for all target frameworks. So even when you don’t want to use the MVVM framework of Catel, you can still use the IoC container, the weak event listener, message mediator, etc.

Non-generic views

One of the arguments of people not using Catel is because the base classes for the views were generic. To use them in combination with Blend or Silverlight forced you to use a very nasty “intermediate” class construction.

Starting with Catel 3.0, we introduced non-generic versions of the views. This means that you can now use the Catel views directly and no longer need to create intermediate classes. So, a control that supports a nested scenario now has this code behind:

  1: public partial class HouseView : Catel.Windows.UserControl
  2: {
  3:     public HouseView()
  4:     {
  5:         InitializeComponent();
  6:     }
  7: }

Then, the xaml looks like this:

  1: <catel:UserControl x:Class="Catel.Examples.SL4.NestedUserControls.Views.HouseView"
  2:                    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  3:                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  4:                    xmlns:catel="http://catel.codeplex.com">
  5: 
  6:     <!-- Your content -->
  7: 
  8: </catel:UserControl>

ViewModelLocator and ViewLocator

With the removal of the generic base classes, we had to think of a better way to resolve views and view models. This is done via the ViewModelLocator and the ViewLocator. These are classes that are internally used by Catel to resolve the right view model for a view and vice versa. However, the locators are available in the ServiceLocator so you can use them as well!

FluentValidation

We have introduced an extension for FluentValidation. This means that by simply adding the extension assembly, you can have full FluentValidation support for the DataObjectBase and ViewModelBase.

When is it being released?

So, when will it be released? We plan to release mid March, but we want to await the first beta feedback to make sure everything works like we planned. If you are interested in grabbing a beta, you can use NuGet or simply create a new discussion and we will gladly provide you with a new version.

Event the documentation is in beta, as you can see here:

http://catel.catenalogic.com/3.0-beta/

It contains a guide on how to move from an earlier version of Catel to the latest and greatest.

Recently I needed weak actions for the message mediator implementation of Catel. I looked at a few examples and most seem to do something like this:

   1: public class WeakAction

   2: {

   3:     private readonly Action _action;

   4:     private WeakReference _reference;

   5:     

   6:     public WeakAction(object target, Action action)

   7:     {

   8:         _reference = new WeakReference(target);

   9:         _action = action;

  10:     }

  11:     

  12:     public bool IsAlive

  13:     { 

  14:         get { return (_reference != null) ? _reference.IsAlive : false; }

  15:     }    

  16:     

  17:     public void Execute()

  18:     {

  19:         if (_action != null && IsAlive)

  20:         {

  21:             _action();

  22:         }

  23:     }    

  24: }

There are 2 downsides of this approach:

1. It doesn’t allow static handlers
2. It causes memory leaks

The problem

So if you are using such an implementation of a weak action, all your alarm bells should be ringing right now. The issue is in the storage of the Action object. The action is a method handler. To be able to call the handler, it must store the reference (as Target property on the Action class) of the target.

However, this means that there is now a reference to the target, so the target can never be garbage collected, so you are now dealing with a big issue in your application because you think that you are using weak events, but you aren’t.

The Solution

I already wrote a true weak event listener once, so this one should be easy. What you basically need to do is to write an open instance delegate, create a handler without a target for it and late-bind the handler. Sounds complex, but once you get the grip of it, it’s pretty simple. Below is the code for a non-generic Action. All this code (and the generic implementation) can be found at http://catel.codeplex.com.

   1: public class WeakAction

   2: {

   3:     public delegate void OpenInstanceAction<TTarget>(TTarget @this);

   4:     private Delegate _action;

   5:     private WeakReference _reference;

   6:     

   7:     public WeakAction(object target, Action action)

   8:     {

   9:         _reference = new WeakReference(target);

  10:         

  11:         var targetType = (target != null) ? target.GetType() : typeof(object);

  12:         var delegateType = typeof(OpenInstanceAction<>).MakeGenericType(targetType);

  13:  

  14:         _action = Delegate.CreateDelegate(delegateType, null, action.Method);        

  15:     }

  16:     

  17:     public bool IsAlive

  18:     { 

  19:         get { return (_reference != null) ? _reference.IsAlive : false; }

  20:     }    

  21:     

  22:     public void Execute()

  23:     {

  24:         if (_action != null && IsAlive)

  25:         {

  26:             _action.DynamicInvoke(_reference.Target);

  27:         }

  28:     }    

  29: }

Recently I was working on true weak actions and wanted to do something like this:

   1: public class WeakAction<TParameter>

   2: {

   3:     public delegate void OpenInstanceGenericAction<TTarget>(TTarget @this, TParameter parameter);

   4:  

   5:     public WeakAction(object target, Action<TParameter> action)

   6:     {

   7:         var targetType = (target != null) ? target.GetType() : typeof(object);

   8:         var delegateType = typeof(OpenInstanceGenericAction<>).MakeGenericType(targetType, typeof(TParameter));

   9:  

  10:         _action = Delegate.CreateDelegate(delegateType, null, action.Method);

  11:     }

  12: }

I was pretty sure I was doing it all right. In this code, I create a generic open instance handler to make sure I can invoke the method without referencing the instance itself. This allows me to write true weak actions.

Anyway, the error that pops up is:

System.ArgumentException: Cannot bind to the target method because its signature or security transparency is not compatible with that of the delegate type.

Scratching my head over and over again, for about 1 hour, something came into my mind that couldn’t be true: would it be that I have to define the TParameter first, and then the TTarget, even when the delegate uses them in another order?

The answer seemed to be yes!

Apparently, you need to specify the order of arguments. So, because the delegate is part of a class defining the first generic argument (TParameter), you need to specify that first. So, it is not the order in which they are used inside the delegate, but the order of definition.