Wednesday, June 6, 2012

C# Quiz: Working with Value Types

A while ago, I read Jefferey Richter's book CLR via C#. I can say this book is a really great resource for everyone who wants to know how CLR internally works.

One really interesting topic was the difference between reference types (classes) and value types (structs) in .NET.

Here's a little quiz. Give yourself a few seconds to try to figure out what the console output will be. When you think you got it, scroll down and compare your assumptions with the actual outputs.

namespace ConsoleApplication1 {
   interface IValueProvider {
      void SetValue(int i);

   struct MyValueProvider : IValueProvider {
      private int _value;

      public MyValueProvider(int value) {
         _value = value;

      public void SetValue(int value) {
         _value = value;

      public override string ToString() {
         return _value.ToString();

   class Program {
      static void Main(string[] args) {
         MyValueProvider v = new MyValueProvider(1);

         MyValueProvider v2 = v;

         IValueProvider i = v;

         object o = v;


Give yourself a few seconds before you scroll down to read the disclosure.

You think you got it?



Here is the output to the console:

Kudos to you if you have been 100% correct! If you have been surprised of one or more outputs, let me explain.

Boxing and Unboxing

The main reason for the above output is how CLR does boxing and unboxing.

Reference types (classes) like strings, database connections and most other types in .NET library always live on the application domains managed heap, that is managed by the garbage collector. Value types (structs) like Guids, ints and all other primitives live on the threads local call stack.

Whenever CLR needs a reference of a value type, it needs to create a copy of the local stack memory on the heap (what is called boxing). Whenever a heap reference is cast into a value type on stack, it becomes copied from global heap into a local piece of memory (what is called unboxing).

Now find the next chapter for explanations of the initial quiz.


First section:
MyValueProvider v = new MyValueProvider(1);
Shows "1", nothing special no surprise.

Second section:
MyValueProvider v2 = v;
Shows "1". MyValueProvider is a struct what means that "v" is no reference to an instance of MyValueProvider on the heap but the instance itself and allocated on the stack. The assignment "v2 = v" causes a copy of MyValueProvider into a new instance on the stack. As a result, any changes of "v2" will not affect "v".

Third section:
IValueProvider i = v;
Shows "1". MyValueProvider implements the interface IValueProvider. While MyValueProvider is a value type, interfaces are always handled as reference types and so "i" causes a boxing of our value onto the heap. Any changes of the interface reference will not affect the original instance "v".

Fourth section:
object o = v;
Shows "1". The assignment of "v" with a variable of type Object causes a boxing of the value type onto the heap. "((MyValueProvider)o)" causes a local (stack) de-referencing (unboxing) of the previously heap copied version of our value. Since we now have another, new instance of our value type the rest of the line ".SetValue(4)" will only affect the unboxed instance but will not affect the boxed value on the heap. (If you would try to assign a property instead of calling a method, you would actually get a compiler error, since C# compiler knows that the property assignment would never affect the boxed value type.)

Fifth section:
Shows "5". As explained for third output line, interfaces do always need a reference on the heap. But this time we "o" already represents a heap reference. CLR does not need to create a copy of the boxed value but can use the existing one. The boxed value type becomes cast into IValueProvider and calls the method on it. Therefore a call of the interface method will change the value of our boxed value type instance.

Little Conclusion

Some of the results might look a little spooky for the first glance. However, we use to work with value types all the time and everything usually works fine. There is a general guideline to keep in mind that helps to avoid running into one of the above shown issues.

Value types should always be immutable, what means they should not change their internal values, once they are created. If you keep this in mind you are protected against unexpected boxing/unboxing behavior.

Tuesday, May 15, 2012

Simplify Null-Reference Handling of Properties in C#

A few months ago I wrote about a simple design rule that helped us to get almost rid of this annoying "Object reference not set to an instance of an object" exception, here.

In this post I want to show another way to simplify the handling of null-references. In particular, collection properties that can be null.

Let's start with a small piece of code:
class Customer {
   public string Name { get; set; }
   public ICollection<Contact> Contacts { get; set; }

// ...

Customer customer = GetCustomer(1);
foreach (var contact in customer.Contacts)

Looks fine and there seem to be nothing special to talk about. Due to the rule I showed in the other post, GetCustomer will never return null. Unfortunately, the Contacts property is still not guaranteed not to be null. If Contacts is null we are again in front of our old "friend" NullReferenceException.

The straight forward approach is to always add an if-condition to ensure that our property is set to any value before we can iterate through.
Customer customer = GetCustomer();
if (customer.Contacts != null) {
   foreach (var contact in customer.Contacts)
My problem with this is that developers (like me) tend to be lazy. We don't want to always add the condition and the additional scope.

Wouldn't it be nice to be able to write something like this?
Customer customer = GetCustomer();
foreach (var contact in customer.Contacts.NotNull()) // <= notice the NotNull()
Luckily .NET 4.0 makes this possible with a simple extension method. Extension methods are not only static at design-time, but also behave as any other static methods at run-time. Any call of an extension method on a null reference will be routed into the extension method without any reference validation.

Due to this behavior of .NET, we are able to create this very simple extension method.
public static IEnumerable<T> NotNull<T>(this IEnumerable<T> collection) {
   return collection ?? new T[0];

Yes, this only helps when iterating through the list. But, from my experience, this covers about 90% of use cases.

Attention, keep in mind to always return an empty, immutable collection - like an array. If you would return an instance of a List<T> you might run into unexpected behaviors. The list would not become assigned to the parent component and any changes would not take any effect to the parent.

Monday, May 14, 2012

Yet Another Dependency Injection Container

Well, this might sound odd to some of you. However, in this post I want to present yet another dependency injection (DI) container.

If you are doing fine with your's feel free to stop reading here. If there are some things that could do better or you are just interested in new options give me a chance.

Due to the fact that the containers feature set isn't that small anymore, this post is only a rough overview of some of its features. Please find a complete documentation attached at the bottom of this post.

Why Yet Another Dependency Injection Framework?

Yes, at first glance FluffyContainer (don't ask why this name) is yet another dependency container. However, FluffyContainer comes across with a combination of two aspects that I've been missing in other dependency injection (DI) frameworks until now.

By my experience there are two different kinds of DI frameworks out there. The one type is feature rich, but relatively slow in creation of objects. The other type are those that are really fast, but poor in features. FluffyContainer combines those two aspects.

Overview of Features

FluffyContainer supports all common DI framework features, like:
  • Type to type mappings (with and without named mappings)
  • Mapping to custom factories
  • Singleton behavior for mappings
  • Calling of parameterized constructors
  • Field injection
  • Property injection
  • XML based mapping configuration
  • In code mapping configuration

In addition to this, it also supports some more advanced features, like:
  • About 20 times faster than other containers
  • Caching of, once initialized, mappings to make the creation of the container very cheap
  • Two types of internal factories. One with focus on high performance and another one that focuses on low-trust environments (like in some ASP.NET environments)
  • Thread Singletons
  • The container and most of its related components are thread safe; including management of singletons
  • Custom type initialization by automatically calling a configurable init method
  • No need of referencing .NET DLLs like System.Web that would require a full .NET framework installation and wouldn't work with the client edition
  • Customization with builders (aka plug-ins)


One of the main reasons for the development of FluffyContainer was the bad performance of other DI frameworks. If DI can only be used to create the large components but has to be skipped for the smaller once it did not yet reach its target yet.

Whenever people argue that DI is slow, there is somebody else - often somebody who calls himself a matured Software Architect who explains that DI has nothing to do with performance. It is all about abstraction, coupling and composition. I disagree with those Architects! As long as I'm not able to abstract (almost) every component initialization with DI, there are always points of tight coupling that will need to be refactored when a new type hierarchy is required.

Nevertheless, there are always some massively performance critical parts of a system, where DI will most likely never become the shiny hammer. When it comes to arrays instead of lists, emit instead of reflection byte buffers and cost of stack allocation, you are on a point where DI will probably never the way to go. In this scenario, abstraction and composition in general is often the wrong decision. But in all other scenarios, performance should not the reason not to use it.

By default, FluffyContainer is about 20 times faster than the fastest other well-known DI frameworks. On top of this, it provides the possibility to create a factory for a specific mapping. With this factory the creation of components is about 90 times faster than other DI frameworks, while it still provides all features the container. The factory is about 80% (not times) slower than a hardcoded factory, what is a difference I can live with in majority of a system.

Here are some results of my performance tests with some other feature full DI frameworks. The X axis shows the count of items created in my tests, the Y axis shows the duration in milliseconds it took to create the instances.

If you wonder why you see only 3 lines, this is because the lines of "Hardcoded", "FluffyContainer" and "Fluffy Factory" are all overlaying at the bottom of the diagram.

Since this diagram doesn't tell you very much about the three lines on the bottom, here is another diagram that shows only those three competitors.

As you see, out of the box FluffyContainer is about 8.5 times slower than a hardcoded factory. If you know that you will need to create larger amounts of the same component it can be useful to take advantage of the available factories. Especially because the creation of a factory is really cheap.

If you prefer numbers over diagrams, here are my test results.
CountHardcodedFluffyContainerFluffy FactoryOther Fast DIOther Slow DI

I'm not going to talk about the names of the other DI frameworks I used in this test since this is no bashing for any other framework. But trust me, the fast one is one of the fastest, serious DI frameworks.


Here is a quick overview of how to configure the container in XML or in code.

FluffyContainer supports two different kinds of configuration; XML and a expression based in-code mapping syntax. Here is a short sample of both configurations.

<?xml version="1.0" encoding="utf-8" ?>
      <assembly name="System.Data, 
      <assembly name="DependencyInjectionSamples"/>
      <namespace name="System.Data.Common"/>
      <namespace name="System.Data.SqlClient"/>
      <namespace name="DependencyInjectionSamples"/>
      <map from="IMyComponent" to="MyComponent"/>
      <map from="DbConnection" to="SqlConnection" name="db1"/>
      <map from="IMyComponent" toFactory="MyComponentFactory" name="factory"/>

      <map from="IMyComponent" to="MyComponent" 
           singleton="appDomain" name="singleton"/>
      <map from="IMyComponent" to="MyComponent" 
           singleton="thread" name="threadSingleton"/>

      <map from="MyComponent" to="MyComponent" name="fpConst">
         <field name="_foo" value="123"/>
         <property name="Id" value="1"/>
      <map from="MyComponent" to="MyComponent" name="fpMapped">
         <property name="Database" from="DbConnection"/>
Read XML in C#
var resolver = XmlDependencyResolver.FromFile("DependencyInjection.xml");
FluffyContainer container = new FluffyContainer(resolver);
using FR.DependencyInjection;


FluffyContainer container = new FluffyContainer();


         .WithField("_foo", 123)
         .WithProperty("Id", 1)

         .WithProperty("Database", typeof(DbConnection), null);

When using XML mappings, you are still able to add additional in-code mappings in code, after the container was initialized from an XML.


After configuring the container, you can use it in your project source code by using the Resolve method to create new instances. Use the Release method to ensure a correct clean-up of IDisposable implementing components, while taking singleton configurations into account.

var comp = container.Resolve<IMyComponent>();
// use comp

To simplify error handling for disposable components, especially when working with more than one resource, consider using ActivationScope when resolving several components. The activation scope will automatically manage a disposing of all resolved instances when it runs out of scope.
using (ActivationScope scope = container.CreateScope()) {
   var comp2  = scope.Resolve<IMyComponent>();
   // do work
   // disposing of comp2 will be skipped when the scope becomes disposed
   // ..
   var mydb = scope.Resolve<DbConnection>();
   // do work
   // mydb becomes automatically disposed when the scope becomes disposed


As I stated at the beginning of this post; yes, this is yet another dependency injection (DI) framework. Nevertheless it is relatively grown in its set of features and its performance blows all other frameworks (that I know) out of the building. If you already successfully work with DI in your project, stay with whatever you use. If you start a new project or if you are completely new in DI, consider to give it a chance.

Don't forget to check the documentation related to this post that will describe all features of the framework in deep.


FluffyContainer is part of my core libraries that I've published in another post, FR.Core Libraries.

Here you can find all files in the version that was used in this post:

Sunday, April 22, 2012

FR.Core Libraries

Okay, this becomes a special post. Fist, due to time pressure I have to start with saying sorry, because this might become a little sloppy written.

Since 1st March I'm working in a software consulting company. Until now, I'm working as software developer, architect now, since about 14 years (what slightly shocked me as I realized it). I've started with VB6 and C++ and I'm part of the .NET development community since version 1.0 - ten years ago.

Since I always loved my job I've always spent some of my spare time with testing new features and developing components. My focus has always been on framework design and back-end development. Over the years my private frameworks became quite large and I realized more often that many requirements in projects at work are already covered by my private libraries. Every now and then I allowed myself to copy parts of my library into my business projects. Now, as a consultant, there might be quite a bunch of different projects over the next years and caused by the nature of consulting projects there might be copyright issues when I keep doing as in past.

To avoid copyright issues, I decided to post my private components here. For now I share my "Core" library that covers the most common and basic requirements for software like:
  • Compilation of custom C# for scripting purposes in dynamic parts of an application
  • A very fast factory framework that supports different kinds of factories, from Emit code generation to .NET Activator usage, depending on the current environments trust level
  • Some collections like:
    • A ConcurrentHashSet
    • A RingBuffer (that I've already published a few years ago)
    • A writable version of a ILookup
    • Special dictionaries and others
  • A configuration framework that replaces the .NET configuration and supports different kinds of sources (like XML files, SQL databases, WCF services or stubs for testing).
  • A fast dependency injection framework that works much faster than Microsoft Enterprise Libraries (MEL) Unity. Since the whole IoC is based on interfaces it can easily be replaced by other frameworks like MEL or Ninject
  • A logging framework with custom devices like SQL Server and a integration of log4net.
  • Several other components

Apart to this "Core" library, I will most likely share my other libraries, like "Data" and "Enterprise Services" over the next weeks. But at the moment I will start up with the "Core".


I've invested much time and wrote hundreds of unit tests to find potential issues, nevertheless software might never be free of bugs but only be free of known bugs. If you decide to use the library or parts of it and you find a bug I'd enjoy a feedback about the bug but no bashing, thanks. If I find the time, I'll fix the bug but this is not guaranteed.

License Decision

I decided to set the library under MIT License to enable everybody to use parts or the whole library in any project without any license issues. Feel free to merge parts, or even the whole library, into your projects without any restrictions to your own project.


Copyright (C) 2012 Florian Reischl

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.


Open Source Platforms

In future this library might become moved to one of the common open source platforms like Codeplex. Since I don't know about the restrictions and requirements I decided to start with a simple post here.

If I move the source code to one of the open source platforms I'll add an information here.


Here you can find the currently published components:
  • FR.Core, the main "Core" library
  • FR.Core.Test, the NUnit test cases for the FR.Core.dll
  • FR.Test.Core, a library that provides some unit testing helpers. You will need this library if you want to execute the unit tests of the other libraries.
  • FR.Logging.Log4Net, a log4net based implementation of my logging interfaces
  • FR.Logging.Log4Net.Test, the NUnit tests for the FR.Logging.Log4Net library