Using ImportMany For Lazy Initialisation With Reactive Extensions (RX) and WPF/Prism

Working on a WPF application, I had a requirement to allow a user to monitor the status of a number of connected services – the status of some services could fluctuate many times per second.

There were a couple of issues that needed to be considered:

1. How would I get hold of these monitored ‘services’?  Could I just create new instances and pass them into my monitoring class?  Unfortunately not, as I didn’t know until runtime what these services were.
    
2. How would I throttle the status updates to make them more presentable to the user without resulting in some sort of flashing Christmas tree effect?
     
3. How would I unit test the monitoring behaviour?
    
4. How would I display the status of specific items in an easy to understand manner?  Did I want to wait for a disconnect status and show that in, say, red? 

How Slow is Repeatedly Parsing an Expression for INotifyPropertyChanged

Introduced in .NET Framework v4.5 (as a C# 5.0 compiler feature), the CallerMemberNameAttribute allows you to determine the method or property name of the caller of a method.

This comes in very handy if you’re adding logging code, or in the case of with WPF you’re using models based on the INotifyPropertyChanged interface, where you need to fire the PropertyChanged event passing along the name of the property that’s changed.

Prior to the availability of CallerMemberName, you had a couple of choices when calling the PropertyChanged event:

1. Pass a hard-coded string to identify the property name.
   This has clear drawbacks – what if the property name changes/identifying code dependent on the property?
    
2. Parsing an expression tree that represents a concrete class property
   Handy, because you’re referring to a class's property  

There are plenty of examples available showing how to parse an expression tree (see below), but be very careful, parsing an expression tree is very, very slow compared to using the CallerMemberName or passing in a string to identify the property. 

Improving Struct Performance By Overriding GetHashCode()

In an earlier post, I discussed the pitfall of using structs in C# to store data and failing to override the Equals method.  In this post I’ll look at the GetHashCode method and how not overriding the default implementation can have a drastic effect on the performance of a C# application.

I was asked by a client to investigate the performance of a C# WPF application; users were concerned that performance across certain areas just didn’t feel as fast as it ought to be – particularly during busy times of a trading day.  

After analysing the code and using an automated profile application (ANTS by Red Gate) I narrowed down the bottle neck to a struct had been used to store stock market prices.

Improving Struct Performance By Overriding Equals()

I’ve spent a few days analysing the performance of a C# WPF application.  The client’s users were concerned that performance across certain areas just didn’t feel as fast as it ought to be – particularly during busy times of a trading day. 

That might sound pretty vague, but often as developers that’s all we get.

There are plenty of resources available that go into a great level of detail on the best practices to follow when designing apps.  It helps to understand what .NET does under the hood, in many aspects, but it’s important to remember that there are many layers in which subtle coding designs can negatively affect performance.

I’m going to describe some interesting implementation details which I discovered were the cause of performance issues that the users were complaining about.  This particular blog covers structs and how slow Equals calls can be – please see my other blog entry for similar results found by examining the default GetHashCode implementation.

Adding Template Classes to Visual Studio 2013's "Add New Item" Screen (NUnit Test Class)

When using Visual Studio,  if you follow Test Driven Development principles, then you're probably used to repeatedly following these steps when adding a new test class (using NUnit as an example):

1. Right click on Solution Explorer
2. Click Add  and then New Item
3. Selecting Class from the list of items
4. Entering your test class name
5. Typing in or pasting similar looking lines of code:

using System;
using NUnit.Framework;
 
namespace MyProject
{
    [TestFixture]
    public class MyTestClass
    {
 
        [Test]
        public void Test()
        {
        }
 
    }
}