[PostSharp] Ease the creation of configuration sections

In this article, I'll show yet another use of PostSharp, this time focusing on the ConfigurationSection class. If you look in the MSDN at the articles which explain how to use the ConfigurationSection, you may have noticed that the code you need to write is repetitive, tedious, and error-prone:

[code lang="csharp"]public class PageAppearanceSection : ConfigurationSection { [ConfigurationProperty("remoteOnly", DefaultValue = "false", IsRequired = false)] public Boolean RemoteOnly { get { return (Boolean)this["remoteOnly"]; } set { this["remoteOnly"] = value; } } [ConfigurationProperty("font")] public FontElement Font { get { return (FontElement)this["font"]; } set { this["font"] = value; } } [ConfigurationProperty("color")] public ColorElement Color { get { return (ColorElement)this["color"]; } set { this["color"] = value; } } }[/code] As you can see, you have to put the ConfigurationPropertyAttribute on top of each property, and to make calls to an indexer to the Get and Set methods of the properties, using the same name you used in the attribute.

Doesn't this repetition look like to be a good candidate for an aspect?

[PostSharp] [Caliburn] Automatic IEventPublisher subscription and publication

If you develop in WPF using the MVVM pattern, you have certainly heard about the Event Aggregator pattern, which allows, as the MSDN says:

decoupling of publishers and subscribers so they can evolve independently.

There are several implementations of this pattern:

Of course, as the title of this article told you, we are going to use the latter, and I will propose an implementation of a PostSharp aspect which will help us to subscribe to events, publish them, and dispose the subscriptions when the view-model is deactivated.

Server Migration

A small post to warn you that the site may be unavailable a few moment, because I'm currently migrating it on another server. I hope the transition will be smooth, and won't take too much time. See you later! (I hope...) Edit: The migration seems to have been successfully completed. All should be working now…

[Caliburn Micro] Action filters - Dependencies on "properties of properties", using the Reactive Extensions

By default, Caliburn Micro (CM) doesn't contain the action filters which belong to Caliburn (C). There is a recipe on how to implement them back in CM, but unfortunately it doesn't cover all the initial functionalities which are in C.

One feature missing, and that I needed, is the possibility to depend on "properties of properties".

With the recipe, you can add a dependency between the property of a view-model (VM) and another property of this same VM. Thus, when the latter property is changed, the PropertyChanged event of the VM is fired, resulting in the update of the availability of the action on which the Dependencies attribute is put. But what it doesn't allow you to do, is to define something like:

[code lang="csharp"][Dependencies("OtherProperty.ChildProperty")][/code] This would update the availability of the action if OtherProperty implements INotifyPropertyChanged and if the ChildProperty is modified. You could even use something like:

[code lang="csharp"][Dependencies("OtherProperty.*")][/code] which would update the availability if any of the properties of OtherProperty is modified.

But let me show you how I implemented this feature on top of the recipe, with the great use of the Reactive Extensions.

[PostSharp] Don't NotifyPropertyChanged all properties

This article will show you another improvement which can be made to the DataBinding sample aspect found on SharpCrafters, after the Fire INotifyPropertyChanged.OnPropertyChanged for read-only properties depending on other properties article.

By default, the aspect will fire the PropertyChanged event each time any property is changed. But what if you don't want some of them to fire the event? Or what if, as it happened to me, you set the value of a property, and must do some work in the property setter, even if the new value of the property is the same as the old one?

The latter example is a bit odd, but in the default implementation of the aspect, in the OnPropertySet method, you have this code:

[code lang="csharp"]if ( args.Value == args.GetCurrentValue() ) return; args.ProceedSetValue();[/code] If the new value of the property is the same, the aspect will return, and then never call the args.ProceedSetValue(); method, which will avoid your code to be called in the property setter.

In this short article, I'll show you how to change the aspect, to call the OnPropertyChanged event on all properties, excepted those which are marked with a custom attribute.

[Caliburn Micro] How to use the same view for multiple view-models

The default behavior of Caliburn Micro (CM), when it must locate a view from a view-model, is very straightforward: it takes the full name of the view-model, replaces the word "Model" by an empty string, and locates a view with this new name.

One problem with this way is that you must exactly have one view per view-model. So, if you have an abstract view-model, with multiple derived view-models, which only set some filters on the displayed data, you must have one view per derived VM. Which is kind of annoying, useless, and error prone.

In this short article, I'll show you how to easily implement a new feature which will allow us to specify, with an attribute on top of the VM, the view we want CM to display when we activate the VM.

English twitter account

As I speak in french on my current twitter account, and because I choosed to write my blog posts in english, I decided to create a new twitter account which would be in english too, and where I would talk almost exclusively about programming, .Net, and the related technologies revolving around it. I hope this…

[PostSharp] Fire INotifyPropertyChanged.OnPropertyChanged for read-only properties depending on other properties

One problem of the INotifyPropertyChanged aspect concerns automatic notification of read-only properties which depend on other properties.

Indeed, say you have this class, on which the aspect is applied:

[code lang="csharp"][NotifyPropertyChanged] public class Test { public string FirstName { get; set; } public string LastName { get; set; } public string FullName { get { return FirstName + " " + LastName; } } }[/code] If you change the values of FirstName or LastName, the OnPropertyChanged event will be fired, and the view will be able to display the new values of the properties. But if a control of your view is bound to the FullName property, it won't be updated. A solution would be to declare FullName as an automatic property, and update it in the setters of FirstName and LastName. Not very practical.

In this article, I will show you how to extend the aspect, in order to make it fire the event for dependent properties when a "parent" property is modified.

[Ninject] Use one database session per view-model

One very useful web page I've read before beginning to code on my new project was this one: Data Access - Building a Desktop To-Do Application with NHibernate, from the well-known Ayende. In this article, among other hints and best-practices, he says, at the end of the Managing Sessions chapter:

The recommended practice for desktop applications is to use a session per form, so that each form in the application has its own session. Each form usually represents a distinct piece of work that the user would like to perform, so matching session lifetime to the form lifetime works quite well in practice. The added benefit is that you no longer have a problem with memory leaks, because when you close a form in the application, you also dispose of the session. This would make all the entities that were loaded by the session eligible for reclamation by the garbage collector (GC).

There are additional reasons for preferring a single session per form. You can take advantage of NHibernate’s change tracking, so it will flush all changes to the database when you commit the transaction. It also creates an isolation barrier between the different forms, so you can commit changes to a single entity without worrying about changes to other entities that are shown on other forms.

While this style of managing the session lifetime is described as a session per form, in practice you usually manage the session per presenter.

We'll see now how to implement this behavior, with Caliburn as the MVVM client framework, and Ninject as the dependency injector.