Yesterday I was converting an old work-related project to the new csproj structure (using this very helpful tool by Hans van Bakel). Tackling compilation warnings one by one, I was finally left with this one:

Warning AL1073 Referenced assembly 'mscorlib.dll' targets a different processor

Some Googling revealed that this was related to .resx files and x64 platform targeting. Unfortunately, the workarounds offered on Stack Overflow didn't quite work for me. The warning was replaced by two warnings. The original one, plus this:

There are many isolation frameworks around that make writing unit tests relatively simple. It's highly unlikely that any single framework will meet all your needs, so writing your own utilities can be useful in order to make your tests easier to write and – perhaps more importantly – read.

I regularly find myself wanting to verify that a certain dependency is called in the right way by my system under test. This includes passed argument values, which can be complex objects themselves.

Yesterday I ran into an interesting (and dangerous) little detail about the C# compiler regarding virtual (field-like) events; they do not behave as you might expect. Consider this code, which I've simplified from a real world example of some refactoring gone wrong:

public abstract class MyClassBase
{
    public virtual event EventHandler<EventArgs> MyEvent;

    public void DoStuff()
    {
        if (MyEvent != null)
        {
            MyEvent(this, EventArgs.Empty);
        }
    }
}

public class MyClassDerived : MyClassBase
{
    public override event EventHandler<EventArgs> MyEvent;
}

To my surprise, when one subscribes to MyEvent, it will never be called:

Note: This article was edited after a Gonçalo Lopes presented me with a better solution. Thanks!

Every now and then you run into a situation where you wish your programming language of choice was just a tad more flexible than it actually is. For example, constructors in C# always have to directly call one of the base type constructors as the first thing they do (or do they? keep reading).

Yesterday I ran into a situation where I would like my derived class to always use the same implementation^* for a certain injectable dependency. No problem:

public class FooBase
{
    public FooBase(IDependency dependency)    { /* stuff here */ }
}

public class MyFoo : FooBase
{
    public MyFoo() : base(new MyDependency()) { }
}

The dependency is created on the fly and my base class constructor is happy. However, my derived class also needed to make use of this dependency and my base class does not expose any property or field for me to access it. So before calling the base constructor, I would have liked to store a reference to this newly created MyDependency object.

The evolution of spam

Many blog owners will be familiar with one particular pest on the internet: spam bots. This blog is no exception, but I was determined to keep my pages clear of digital graffiti even when I don't have much time to post regularly.

Fortunately there are some nice and unobtrusive countermeasures available, like Akismet. They work pretty much like the spam detection for your email. For some time, this used to be enough to keep the spam bots at bay, but spammers are constantly changing their angle of attack. Many comments that are posted nowadays don't even contain any links anymore. With some luck, they can even pass for a comment from an interested reader. I'm not completely sure how exactly this helps the spammer, but no doubt they are trying to raise the reputation level of the IP address or email used to post the comment with, so t hey are more likely to pass through filters like Akismet later. In any case, spam filters are not as effective against these messages as they are against something containing one or more actual links.

Rethrowing Exceptions

Normally, if you have to rethrow and existing exception in .NET, you should use the throw keyword without any parameters:

try
{
    // Code that can generate exceptions here
}
catch (Exception ex)
{
    // Do some logging or whatever
    throw;
}

Using throw ex; would cause the stack trace of the exception to be lost, in which case we lose some valuable information. However, this only works inside the catch block that caught the exception in the first place.

Sometimes, you need to rethrow the exception at a later point outside the catch block, but of course we want to preserve the stack trace.

Contents:

• Part 1: Explaining the Issue
• Part 2: Working on a Solution
• Part 3: Alternatives

Limitations

In hindsight to the created solution, there is an issue that cannot be addressed in this way: When a consumer fails to call Teardown properly at the right time for constructed objects, the DisposingSharedLifetimeManager will not behave as expected. For some, this may be a big issue, because it may not be very customary to bother to call Teardown when using Unity, precisely because it usually does nothing useful anyway.

Alternative Solutions Using Unity

One alternative is to use a wrapper of sorts and register that in the container instead. The usage would look something like this:

Contents:

• Part 1: Explaining the Issue
• Part 2: Working on a Solution
• Part 3: Alternatives

Two New Lifetime Managers

Having explained the issue, how can we solve it?

Before starting, I should mention that my implementation is based on previous work by Rory Primrose, who wrote an extension that changes the behavior of the TransientLifetimeManager in order to dispose of objects. He does an excellent job of explaining some of the rationale behind his implementation, so be sure to read his article.

I've placed the complete source code for my article (including some quick unit tests) on GitHub.

My approach is a little different: I did not want to change the default behavior of Unity, so instead I defined two new lifetime managers to explicitly set the desired behavior with: DisposingTransientLifetimeManager and DisposingSharedLifetimeManager.

DisposingTransientLifetimeManager

This lifetime manager behaves pretty much like the built-in TransientLifetimeManager; every time a new object is created. The only difference is, that on Teardown of any object, we will call Dispose() on objects that were created as a result of the original build-up operation (provided they are using this lifetime manager, of course).

Contents:

• Part 1: Explaining the Issue
• Part 2: Working on a Solution
• Part 3: Alternatives

Introduction

In modern software development, the use of Dependency Injection is a very important principle. It allows you to build large systems with properly decoupled and testable components. The use of Inversion of Control containers is a popular way of implementing Dependency Injection. If you are unfamiliar with these terms, this article probably isn't for you; I suggest you read Martin Fowler's excellent article about DI and IoC instead :)

In the .NET world there are probably dozens of different IoC containers available. They all serve the same basic need, but there are important differences in the features they offer. One popular IoC container is Unity, created by the Microsoft patterns & practices team.

Just because it's popular, doesn't mean Unity is perfect however. In this multi-part article, I will try to address some issues around classes implementing IDisposable in combination with Unity.

Every now and then, you run into a piece of code that makes you wonder how it ever got into existence. I personally have a bit of a fascination for these things. I read TheDailyWTF regularly for amusement, but I always try to understand what caused these usually inventive but nevertheless misguided pieces of work. When I run into something within my own circle, understanding may also help me prevent problems in the future.