I’ve been playing around with it for a month or so now and it is wonderful to have.  This isn’t the sort of tool that you whip out all the time, but when you need it, you need it.  No doubt there.

But lets throw out some software development methodologies first. 

Rule #1: Premature optimization is the root of all evil. (Donald Knuth said that back in 1974 if you have any issues with it).  Again, this isn’t a tool that you should be using all the time.

Rule #2: If you don’t measure, you don’t know.  The is the heart of the engineering part of software development.  At my last Boise Code Camp (March 8, 2008) I had two separate people complain to me about how slow .net was for WinForms.  OK, so what part was so slow?  What were you trying to do?  Was the database properly indexed?  Did you have measurements about what is slow?  Nope.  Nothing.  I can’t comment on their code, I didn’t see it.  But for all they know the problem could have been anywhere in their code.  It could have been the database was improperly tuned, it could be they were running on really slow hard-drives.  They simply did not know.  To me that is not acceptable.

Rule #3: Where-ever you thing the problem is — is wrong.  This really is just a continuation of Rule #2.  But it is directly related to how many people I’ve talk to that get disgusted with me when I talk about ORMs.  “They are too slow” is the answer I get.  Accordingly, I’ve talked to two developers for whom that was true, for the particular application they were writing.  For the rest, their app was slow, so they were assuming it mush be the fault of the ORM — and telling everyone else as much as well.  Also not acceptable.  They did not know where their problems actually were.

I’ve made this mistake too many times to count myself.  Spending countless hours optimizing and tuning code that had no net effect in the end.  I hadn’t tested, and it proved to be wrong.  And how many of you checked that code in anyway, because you didn’t want to see all that time go to waist?

Rule #4: This isn’t the only tool you should be using.  A properly written application should be testable with unit tests.  It should also have unit tests.  If you find the problem with your code, you should be able to reproduce it with your unit tests, measure it from there, and then possibly fix it.  That is the heart of the Red-Green-Refactor motto of TDD.  A code profiler will help you FIND the problem.  Unit Tests should help you FIX the problem and know it is fixed.

Enough already, on to the review

First of, on Rule #4: DotTrace paired with ReSharper actually make a wonderful paring.  The two integrate in together so you can launch DotTrace from your test cases in the ReSharper unit test runner.  That is just plain beautiful.

On Rule #3: DotTrace’s UI is a tree structure that really does allow you to follow the bread crumbs to find where the performance problems are.  Here is a look at SubSonic SubStage (a nice little application that helps generate your SubSonic files for you, as well as show results of the tables).

I was looking at the boot up time of the application.  Using the tree and the small iconography I was quickly able to figure out that a good chuck of time was being spent in the NavigateFileBrowser method.  Below the tree view a listing of the code is displayed as well.

Another quick note about the display, the grayed out text is system code.  DotTrace doesn’t detect a pdb, so it can’t show you the code that is being executed.

On Rule #2: You can store snapshots — and compare them.  Actually there are three ways to compare snapshots.  Through the call tree (showing the call stack), plain view (showing slowest functions first), and Hot Spots (top 100 problem methods). 

It is amazing how often some seemingly benign code will have significant performance impact.  Best part, now you can find out where the problem is…and where it is getting worse.

As for Rule #1, it might take a while to figure out, but it is true. But the key to the rule, and all software development, is to have good tools to help you along.  This is a good tool, and this is just the beginning of its features.

There was one cool bit I saw on the install (yes, I already installed it), was a little graphic showing a light saber with a little bit of text below it: Tools Matter.

I absolutely agree.

So there is a new tool out there for all of you who need help keeping your source code up to snuff, similar to what FxCop does for your API…just at the source code level.  It is called the Microsoft Source Analysis for C# (sorry VB). BTW, there is also a blog.

I happen to have a project that I am in the midst of doing some spring cleaning anyway, so I decided to try it out.  You right click on the project or class you want to check, and select “Run Source Analysis”.  Then in a tool window you will see a list of your failings as a developer.

Right off the bad I had a few issues with the list of failures.  Every code file has to have a header.

Here is my “new” standard header to make it happy:

   1: // <copyright file="Axis.cs" company="DiamondB Software">

   2: //     Copyright 2008, DiamondB Software. All rights reserved.

   3: // </copyright>

Lucky for me ReSharper can make that easy to add, but the ReSharper standard “File Header Text” in the ReSharper options does not allow you to have macros, or that would have been a lot easier.

Also, the Source Analysis does not like underscores on field names.  So this will get a red ‘x’

private string _name;

and that is just not right.  In fact, I want just the opposite. (Note: although, this will make one cranky old dutchman that I know very happy — he doesn’t like underscores).

But lucky for me, it is easy to turn things off, which I do.  Right-click on your project file and select “Source Analysis Settings” and you can change anything you want.  The bad news, it is on a project by project basis.  The good news is that the files are merge-able.   This also means there is a new file that gets added to your project, mine is: Settings.SourceAnalysis.  Be sure to add that to your source control. 

The other thing I like about it: it detects Hungarian notation (a prior sin that I am currently making penance for).  “SA1305: The variable name ‘oElement’ begins with a prefix that looks like Hungarian notation.”  But, if you like that sort of thing, back in the options is a way to tell the tools which Hungarian prefixes are acceptable.

But this could get ugly

OK, there are a few other concerns looming here.  I’m calling it Dueling Source Officers.  One tool will say two spaces between methods, the next will say one space.  One tool like spaces, the other likes tabs.  (for the record, Source Analysis HATES tabs, and thinks multiple lines between methods is plane evil).  The other officer: ReSharper Code Analysis and ReSharper Code Reformat.  Lucky for us ReSharper’s tools are very configurable…but it could take a while to get the two in sync.

Not throw in FxCop (now integrated into the Team Systems version of Visual Studio) and it can get very interesting.

Next steps

The next steps are simple:

1. Learn how to write your own rules (I want my underscores)
2. Figure out how to integrate into Team City and Cruise Control (Code Analysis ships with an MSBuild task), and get something meaning full out of it.

I talked with one of my buddies who is a budding WPF expert who told me I was crazy and needed to get a psychologist.  He is probably right.  But something was telling me that this was a system problem, not a WPF problem.  But for the life of me I wasn’t seeing it.

Every programmer needs a toolbox.  Turns out there are several performance analyzing tools for WPF that ship with the Windows SDK.  One of them is the WPF Performance Suite.  While the tool is really cool…it didn’t help at all.  If you want to check the performance of your WPF application while it is RUNNING, this tool will be great.

My problem was start up.  Here was the breakdown: 60 seconds before I saw a WPF window, 30 seconds before anything displayed.  After that, everything ran fine.  Time for a different tool.  Namely: Process Explorer from SysInternal (via Microsoft.com).

I was able to find my Hello World WPF application in Process Explorer (on my system, all .Net processes are colored yellow), then displayed the lower pane to display the DLLs used by the process.  (BTW: I just confirmed that Windows Live Writer is a .Net application).

I found one interesting dll that was referenced: NCover.  A while back I had installed a trial version of the commercial product (this was not the open source version). I have no idea what it was doing there, but it was there.  In fact, it was referenced in every WPF application that I loaded — including WPF applications that I did not write, like the Subscription Center.

Long story made only slightly longer, I uninstalled NCover and now everything loads in about 10 seconds (a nine fold improvement), but I still don’t know what NCover was doing.  If you know, please let me know. 

If you just want to see what is new: check out this page:
http://www.jetbrains.net/confluence/display/ReSharper/ReSharper+4.0+EAP+Notes

Finally, there is another deal going on at JetBrains.  DotTrace has gone to version 3.1.  For a limited time you can now buy the Personal version of DotTrace for $199.

Note: Ilya Ryzhenkov corrected me, this is just a Beta Candidate.

So where am I supposed to find time to update everyone on Twitter? How is Twitter fitting into your schedule?

You can follow me, but I am not really all that active, at least until I find more time.

The Event Broker Extension QuickStart demonstrates how you can extend the Unity container by adding a custom extension. The QuickStart implements an Event Broker for the container as a container extension and demonstrates the new extension using the StopLight QuickStart application sample.

The Event Broker Extension QuickStart contains three projects:

• EventBroker. This project implements a simple publish and subscribe mechanism that supports multiple event publishers and multiple subscribers.
• EventBrokerExtension. This project implements the custom container extension that allows applications to publish and subscribe to events using attributes or explicitly using code.
• StopLight. This project is basically the same as that described in the Unity StopLight QuickStart, but it uses the custom container extension to manage the publishing of, and subscription to, two events within the application.

Now, why is this Unity EventBroker interesting? Well, if you have ever worked with CAB (Composite UI Application Block) or SCSF (Smart Client Software Factory) then you know one of its main pillars was the implementation of a nice Pub/Sub event subscription framework which Microsoft called Event Broker. This was one of the best things about CAB. Unfortunately with CAB it is an all or nothing deal. You really cannot use the CAB Event Broker without using the rest of the CAB underpinnings.

The Unity implementation of the Event Broker is similar to CABs so you should feel right at home if you have any experience with CAB or SCSF. The one huge benefit is that the Unity Event Broker can easily be integrated into any existing WinForm or WPF application where you would like an easy to manage Event bus to handle all your event traffic.

It really is easy to implement, lets take a look at what you need to do in order to integrate the Unity based Event Broker into your application.

1) Download Unity 1.0 install it and unzip the “Unity QuickStart” package found in the Unity start menu installation path.

2) Compile the EventBrokerExtention and SimpleEventBroker projects.  Then grab the following DLLs found in the EventBrokerExtention bin folder and reference them in your application.
  EventBrokerExtension.dll
  SimpleEventBroker.dll
  Microsoft.Practices.ObjectBuilder2.dll
  Microsoft.Practices.Unity.dll

3) Now open your WinForm application and modify your entry point usually the Program.cs file which in my demo calls the FormMain.cs using a Unity Container like so.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;
using EventBrokerExtension;
using Microsoft.Practices.Unity; 

namespace SampleWinApp
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false); 

            // Create parent container
            IUnityContainer mainContainer = new UnityContainer()
                  .AddNewExtension<EventBrokerBusExtension>(); 

            Application.Run(mainContainer.Resolve<FormMain>());
        }
    }
}

The important thing to notice is that I have wired up the EventBrokerExtention class through the Unity AddNewExtention method.  This will cause all the Events that are properly decorated with the correct attributes to be automatically registered in the EventBroker or SimpleEventBroker class.

You will also want to go and modified all the areas in your code where you are opening other forms to use a Unity container as well.  Here is an example opening a Form called FromA.cs 

//Create container
IUnityContainer myContainer = new UnityContainer()
           .AddNewExtension<EventBrokerBusExtension>();
//Open Form
FormA newForm = myContainer.Resolve<FormA>();
newForm.Show();

Oh, make sure you import the proper libraries on all your forms.

using Microsoft.Practices.Unity;
using EventBrokerExtension;
using SimpleEventBroker;

Now you need to setup all the Event publications and triggers. Let’s start simple, say we have a button on our FormMain that is used to force a data refresh in your application. You would need to add a publish event to your page like so.

//Using an attribute register an event in the EventBroker
[Publishes("RefreshData")]
public event EventHandler RefreshData ;
//Method you will call to trigger the event in the EventBroker 
public virtual void OnRefreshDataChange(object sender, EventArgs ea)
{
    EventHandler handlers = RefreshData ;
    if (handlers != null)
    {
        handlers(this, EventArgs.Empty);
    }
}

On your button click trigger the event like so.

private void buttonRefresh_Click(object sender, EventArgs e)
{
    //Trigger your event 
    OnRefreshDataChange(this, e);
}

Now you need to setup all your Event subscriptions, this is supper easy.  You will need to create a method on all the forms in your application that will handle your refresh command i.e. implements the functionality you wish for each form or control in your application.  So far in this contrived example I have two forms FormMain and FormA.  You would add a method like so to each page.    

[SubscribesTo("RefreshData")]
public void OnRefreshDataFired(object sender, EventArgs e)
{
         //Do something, we need to do a data refresh
}

Now anytime the RefreshData button is pushed the event is fired and all objects subscribed to that event in the EventBroker will be triggered. 

One important step you will want to do is unregister your subscribed events every time a modal form is closed.  Remember we are using the Unity IoC container to open a form which automatically registers all publisher and subscriber event handles on form_load (opened). 

// Unregister your subscription to help prevent runtime errors
private void FormA_FormClosing(object sender, FormClosingEventArgs e)
{
     EventBroker myEB = new EventBroker();
     myEB.UnregisterSubscriber("RefreshData", OnRefreshDataFired);
}

That is about it, I used this to clean up an old legacy application that had Window events thrown everywhere.  The SimpleEventBroker class has several methods you can use to monitor what is going on inside the EventBroker such as GetPublisher, GetSubscribers, etc.

Oh, in my implementation I modified the Dictionary in the SimpleEventBroker class which holds the registered published events to be static, makes it easier if you have lots of modal forms, just make sure the Keys (string values) are unique.

public class EventBroker
    {
        private static Dictionary<string, PublishedEvent> eventPublishers  

        = new Dictionary<string, PublishedEvent>();

After seeing too many duplications across methods in one or more classes, I decided to investigate a way to remove these. I am always looking to remove duplicate code, even code that shares similarities, I look to refator. Removing duplications is important to adapt more easily to change. When a code change is required, we should only have to make it in one place. The following article will show two relatively simple means to address this code smell, delegates and an Aspect-Oriented approach.

The example I am using in this article is seen below. It is a unit test class, StackFixture class, and it is extremely trivial. This is a typical unit test taken from Test-Driven Development in Microsoft .NET. I have added the logging functionality as an easy means to show how these types of DRY violations can occur. While the duplications in this example deal with logging, they could pertain to other, more complex, functionality as well. The approaches to removing duplications across methods in this article can work with these simple scenarios, as well as more complex ones.

Take for example this sample test case. Each test method logs a message before and after executing the test logic. This violates DRY. We want to keep our test logic in our method, but factor out the duplicate logging. Again, if we were not logging, but doing some repetitive logic, we could factor that out as well.

   1: [TestFixture]

   2: public class StackFixture : AbstractBaseFixture

   3: {

   4:     private Stack stack;

   5: 

   6:     [SetUp]

   7:     public void SetUp()

   8:     {

   9:         stack = new Stack();

  10:     }

  11: 

  12:     [Test]

  13:     public void Empty()

  14:     {

  15:         Log.Info("Starting Empty test");

  16:

  17:         Assert.IsTrue(stack.IsEmpty);

  18:

  19:         Log.Info("Ending Empty test");

  20:     }

  21: 

  22:     [Test]

  23:     public void PushOne()

  24:     {

  25:         Log.Info("Starting PushOne test");

  26: 

  27:         stack.Push("first element");

  28:         Assert.IsFalse(stack.IsEmpty, "After Push, IsEmpty should be false.");

  29: 

  30:         Log.Info("Ending PushOne test");

  31:     }

  32: 

  33:     [Test]

  34:     public void Pop()

  35:     {

  36:         Log.Info("Starting Pop test");

  37: 

  38:         stack.Push("first element");

  39:         stack.Pop();

  40:         Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

  41: 

  42:         Log.Info("Ending Pop test");

  43:     }

  44: 

  45:     [Test]

  46:     [ExpectedException(typeof(InvalidOperationException))]

  47:     public void PopEmptyStack()

  48:     {

  49:         Log.Info("Starting PopEmptyStack test");

  50: 

  51:         stack.Pop();

  52: 

  53:         Log.Info("Ending PopEmptyStack test");

  54:     }

  55: }

Remove Duplications with Delegates

Quite simply, we can remove our method duplications using a delegate, in this case, the System.Action delegate. Thanks to Ayende for helping me understand this option. We create a method, TestMethod (as shown below), and add it to our StackFixture class. The method takes two strings (string beforeMessage and string afterMessage) and the Action delegate, representing the test method logic. We will call this method within our test cases.

   1: public void TestMethod(string beforeMessage, string afterMessage, Action action)

   2: {

   3:     // before

   4:     Log.Info(beforeMessage);

   5:

   6:     // invoke our method

   7:     action();

   8:

   9:     // after

  10:     Log.Info(afterMessage);

  11: }

Then, in our tests, we replace the following test method…

   1: [Test]

   2: public void Pop()

   3: {

   4:     Log.Info("Starting Pop test");

   5: 

   6:     stack.Push("first element");

   7:     stack.Pop();

   8:     Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

   9: 

  10:     Log.Info("Ending Pop test");

  11: }

With the same method using our delegate approach.

   1: [Test]

   2: public void Pop()

   3: {

   4:     TestMethod("Starting Pop test", "Ending Pop test",

   5:                delegate

   6:                    {

   7:                        stack.Push("first element");

   8:                        stack.Pop();

   9:                        Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

  10:                    });

  11: }

We can replace each of our test methods with the same TestMethod using the System.Action delegate. It will then easy to omit our before and after strings replacing them with “action.Method.Name,” or some other intelligent logic to determine what to log.

This approach works well, but delegates are often difficult to understand. If this solution suits your needs, make sure the implementation is easily maintainable. What is nice about this approach is how simple it is. There is no need to reference any assemblies outside of the .Net framework, i.e. no third party dependencies.

The Aspect-Oriented Approach

Aspect-Oriented Programming (AOP) is an entirely different animal. It certainly deserves more than just a blog post. Please read more about it online. This article will not explain the details of AOP.

If you are reading this, welcome back. I will assume you are now familiar with AOP. There are several options for AOP frameworks. Some frameworks I have used are Spring.net, Castle Project, and PostSharp. The former two provide IoC capabilities as well. I suggest using a well-supported framework, one with community support and frequent updates. Investigate for yourself, there are several nice options available.

AOP with Castle DynamicProxy

Hamilton Verissimo put together a good sample using Castle’s DynamicProxy. It is a nice, clean implementation.This worked fine for me and would work well in other situations. However, in my scenario, if I were to use this approach, I needed to have each of my test classes extend from MarshalByRef. In addition, I would need to modify the underlying NUnit framework to create my proxies in order to provide advice. Since I could not do the latter, or did not want to investigate, I searched for other AOP options.

The DynamicProxy aproach to solving your AOP needs is a great option. It just did not work in my situation, only because NUnit executes each of my methods. I would need to somehow intercept the creation of my test class, create a proxy of it, and execute the test methods on it.

AOP with PostSharp

Gael Fraiteur’s PostSharp is a great option for AOP needs. It is extremely clean and easy to use. It is the simplest AOP framework I have used. I suggest watching Gael’s video tutorial.

The first thing I needed to do, besides downloading and installing PostSharp, is to add two references to my project, PostSharp.Laos and PostSharp.Public. After that, I create a simple class extending OnMethodInvocationAspect, called LoggingMethodInvocationAspect.

   1: [Serializable]

   2: public sealed class LoggingMethodInvocationAspect : OnMethodInvocationAspect

   3: {

   4:     private ILogger log;

   5: 

   6:     public LoggingMethodInvocationAspect(ILogger logger)

   7:     {

   8:         log = logger;

   9:     {

  10: 

  11:     public override void OnInvocation(MethodInvocationEventArgs eventArgs)

  12:     {

  13:         // before

  14:         log.Info("OnInvocation Before proceed");

  15: 

  16:         // invoke

  17:         eventArgs.Proceed();

  18: 

  19:         // after

  20:         log.Info("OnInvocation After proceed");

  21:     }

  22: }

At this point, all we need to do is apply our aspect on target methods. The “AttributeTargetMembers” attribute can use wildcards. This tells the AOP framework to only intercept those methods in the “MathService” class that start with “Test.” Below is the sample where I specify the target assembly, target type (class or classes to intercept), and target methods to intercept. There are many features beyond what I am showing so do further investigation.

   1: [assembly: ClassLibrary.SampleInterfaces.LoggingMethodInvocationAspect(

   2:     AttributeTargetAssemblies = "ClassLibrary.UnitTesting.Sandbox",

   3:     AttributeTargetTypes = "ClassLibrary.UnitTesting.Sandbox.MathService",

   4:     AttributeTargetMembers = "Test*")]

Finally, my StackFixture class now looks something like this. Notice that the duplicate logging logic is now removed and each test method is prefixed with “Test” in the method name. This is so that PostSharp can filter what methods to intercept.

   1: [assembly: ClassLibrary.SampleInterfaces.LoggingMethodInvocationAspect(

   2:   AttributeTargetAssemblies = "ClassLibrary.UnitTesting.Sandbox",

   3:   AttributeTargetTypes = "ClassLibrary.UnitTesting.Sandbox.MathService",

   4:   AttributeTargetMembers = "Test*")]

   5:

   6: [TestFixture]

   7: public class StackFixture

   8: {

   9:     private Stack stack;

  10: 

  11:     [SetUp]

  12:     public void SetUp()

  13:     {

  14:         stack = new Stack();

  15:     }

  16: 

  17:     [TearDown]

  18:     public void TearDown(){}

  19: 

  20:     [Test]

  21:     public void TestEmpty()

  22:     {

  23:         Assert.IsTrue(stack.IsEmpty);

  24:     }

  25: 

  26:     [Test]

  27:     public void TestPushOne()

  28:     {

  29:         stack.Push("first element");

  30:         Assert.IsFalse(stack.IsEmpty, "After Push, IsEmpty should be false.");

  31:     }

  32: 

  33:     [Test]

  34:     public void TestPop()

  35:     {

  36:         stack.Push("first element");

  37:         stack.Pop();

  38:         Assert.IsTrue(stack.IsEmpty, "After Push - Pop, IsEmpty should be true.");

  39:     }

  40: 

  41:     [Test]

  42:     [ExpectedException(typeof(InvalidOperationException))]

  43:     public void TestPopEmptyStack()

  44:     {

  45:         stack.Pop();

  46:     }

  47: }

The end result, a StackFixture test class with duplicate logging logic removed. The PostSharp AOP framework post-processes the compiled assembly and inserts itself, easily providing points of interception.

The PostSharp approach does involve a third-party dependency, but I feel like it is cleaner than the delegate approach. Gael informed me future versions of PostSharp will provide a more configurable solution than adding the [assembly ...] reference for the aspects, perhaps an XML configuration option. This can be done today, but involves some work.

Whether you use delegates, AOP, or some other approach, remove duplicate code wherever possible. I am happy to use either approach in my projects. There are tradeoffs to either solution, so investigate for yourself.

After looking around and finding nothing, finally a co-worker mentioned clicking "Apply" again. Sure enough that worked. If you come across this problem, access your ReSharper options, ReSharper -> Options -> Environment -> General. Then click "Apply" and see if that resolves it.

Finally, it is back, in all its glory.

The argument for writing your own container was simplicity and the learning curve for new developers on the team. I strongly disagree.

I can’t think of anything simpler than downloading an existing IOC container that has a near flat-line learning curve, like the Castle Windsor container. About a year ago, I introduced it into the team. No learning problems whatsoever. Just read two blog posts about it and you are on your way

But the main reason I disagree is that I strongly believe that we have to provide business value instead of writing yet-another-IOC-container. We have to solve the problems of our customers. They simply don’t care about IOC containers.

Scott Hanselman has a nice list of Dependency Injection Containers. Pick, choose and get over it!