Philip Laureano's Development Blog

Introduction to IL Rewriting with Cecil, Part 1–Rewriting FizzBuzz and the Art of Redirecting Method Calls

2011-05-08T00:59:00.000-07:00

The simplest possible code example that anyone can learn from.

Introduction

When I first started learning IL rewriting and Cecil about several years ago, one of the difficulties that I struggled with was the fact that there were very few practical examples on how to take an existing assembly and modify it at runtime. In many ways, I was stranded in heavily undocumented territory, and needless to say, this lack of documentation made it very difficult to learn how to do anything useful with Cecil.

Meanwhile, in the Year 2011…

It’s now 2011, and I think it’s safe to say that for many people, IL rewriting (much less Cecil) is still a “big mystery wrapped in an enigma containing frustration”. Indeed, Cecil is an incredible library that can let you do some incredible things, but at the same time, it can be very frustrating since the learning curve is still steep and there are still no practical guides for using it. As a user, there must be some sample code out there that shows how to do the most basic tasks with Cecil, right?

Establishing the Feedback Loop

In order to learn any skill (such as IL rewriting), we need to establish a simple feedback loop that allows users to easily experiment with the tools they are given so that they know:

What went wrong if it doesn’t work
Where to fix it if it breaks
How to see the results of their experiments without getting mired in the implementation details of the tests themselves

In this case, we’ll need to set up a basic environment that will let users experiment and learn how to modify assemblies at runtime with Cecil. We will need:

A test fixture that loads a sample assembly and gives users the chance to modify it before reloading the modified assembly into memory (An NUnit base fixture)
A way to display/diagnose any invalid assembly errors that occur due to making changes to the original assembly (PEVerify)
To make it easy to change so that we can experiment with different approaches to modifying IL, thus “closing” the feedback loop

Lost in Bytecode

Given these requirements, where would we even begin? It’s not every day that one decides to randomly parse .NET assemblies and learn how to change the underlying bytecode that ultimately defines their behavior. This can seem like a daunting task for even the most intelligent of budding interlopers, but fortunately for my readers, most of the work has already been done for you in these examples. All you need to do is sit back and scroll down the page, as I proceed to tell you the “ins” and “outs” about Cecil, and the practical lessons learned from rewriting IL. With that in mind, let’s get started!

A WriteLine for Another WriteLine

One of the simplest things that you can possibly do with Cecil is to swap a single static method call for another static method call with the same parameters and the same return type. (It’s a fairly simple operation since both methods have the same signature, and you don’t need to add any additional instructions to make it happen). In this case, I opted to swap all calls to Console.WriteLine() with calls to FakeConsole.WriteLine():

As you can see from the example above, I used a simple LINQ query to identify all the call instructions that needed to be modified. More experienced Cecil users will probably notice that I decided to rewrite all method calls to point to FakeConsole.WriteLine() instead of individually checking to make sure that the method call I was replacing was indeed Console.WriteLine(). Indeed, that was an intentional move, given that the FizzBuzz.Print() method doesn’t make any other external calls to any other methods besides Console.WriteLine().

Assuming that I somehow created an instruction that caused an invalid modified assembly, however, how would I be able to know what went wrong, much less know how to fix it?

PEVerify, how do I love and hate thee…

As it turns out, there is a tool called PEVerify.exe that can tell you whether or not the assemblies that you modify with Cecil are valid or invalid. For example, if I were to remove all the IL instructions out of the FizzBuzz.Print() method, PEVerify would give me the following error message:

(Believe me, it’s much prettier when it’s zoomed out)

PEVerify will examine any given assembly and be able to tell you whether or not the compiler (or in this case, you, the human compiler) made any mistakes in creating the assembly. It can be a very useful tool, and that’s why I modified the sample test fixture to run PEVerify right after the user modifies the sample assembly. If you don’t already have PEVerify installed, make sure you download it and configure the Lesson1 app.config file to point to where PEVerify is installed:

Once PEVerify has been configured as part of the tests, the rest is up to your imagination.

Exploring Method Replacement and Beyond

Now that the basic IL rewriting setup has been laid out for you, the onus is on you to explore the possibilities with Cecil and IL rewriting, even if it means that you have to start with some small, basic steps. In the next installment in this series, I’ll show you how to use PEVerify and Cecil to keep the stack balanced so that you can do things like swap static method calls for instance method calls, and even do things like install runtime hooks so you can change your code as your application is running. Stay tuned!

Dynamically Intercepting Thrown Exceptions with LinFu.AOP 2.0

2011-05-03T18:18:00.000-07:00

A screenshot of LinFu dynamically catching a thrown exception.

On Error, Resume Interception

Another useful thing that LinFu.AOP allows you to do is to intercept (and rethrow) exceptions within your applications at runtime. LinFu makes it so easy, in fact, that all you have to do is add the following lines to your CSProj file:

Exceptionally Simple

To use LinFu.AOP's dynamic exception handling capabilities, all you need to do is make the following call to handle all exceptions being thrown in your application:

Try/Catch Me, If You Can

The call to ExceptionHandlerRegistry.SetHandler tells LinFu to hook the SampleExceptionHandler into your application so that all exceptions that will be thrown will automatically be handled by the given exception handler. Under normal circumstances (where interception is disabled), the call to account.Deposit() will cause the app to crash, but as this example shows, LinFu.AOP was able to intercept the thrown exception before it could crash the rest of the app.

What makes this even more interesting, however, is the IExceptionHandlerInfo instance that describes the context from which the exception was thrown:

More Information Than You Can Throw An Exception At

The IExceptionHandlerInfo interface has enough information to describe the method that caused the exception, as well as having properties such as ShouldSkipRethrow that allow you to decide whether or not LinFu should just swallow the exception and keep running the program as if an exception was never thrown. The ReturnValue property, in turn, allows you to alter the return value of a given method in case you want to resume the method and provide an alternate return value as if no exceptions were ever thrown.

As you can see, LinFu.AOP makes it really easy to transparently handle exceptions in your applications, and if this post saves at least a few developers a few headaches from having to manually diagnose their applications, then I'd consider it to be a gratifying success.

Enjoy!

EDIT: You can get the code examples for LinFu.AOP's dynamic exception handling here.

Intercepting Console.WriteLine and Other Third-Party Method Calls with LinFu.AOP 2.0

2011-04-27T18:30:00.001-07:00

Worth a thousand words

In case you are wondering, yes, that is a screenshot of LinFu.AOP intercepting calls to Console.WriteLine() at runtime.
One of the more useful things that LinFu.AOP can do is intercept calls to third-party assemblies that aren’t necessarily under your control. In fact, LinFu makes it so easy that all you have to do to make the interception happen is add the reference to LinFu like the following lines to your CSProj file just like I did with my SampleLibrary.csproj file:

<PropertyGroup>
<PostWeaveTaskLocation>$(MSBuildProjectDirectory)\$(OutputPath)\..\..\..\lib\LinFu.Core.dll</PostWeaveTaskLocation>
</PropertyGroup>
<UsingTask TaskName="PostWeaveTask" AssemblyFile="$(PostWeaveTaskLocation)" />
<Target Name="AfterBuild">
<PostWeaveTask TargetFile="$(MSBuildProjectDirectory)\$(OutputPath)$(MSBuildProjectName).dll" InterceptAllMethodCalls="true" />
</Target>

‘Automagically’ Delicious

Once you reload and rebuild the solution, LinFu.AOP will automatically modify your code after the build runs so that you can intercept it at runtime. LinFu does this by adding hooks to your code so you can change it as the program is running. In this case, I casted the modified BankAccount class to an IModifiableType instance so that I could add my custom ConsoleInterceptor instance:

// Create the BankAccount class just like normal...

var account = new BankAccount(100);

// Notice how LinFu.AOP automatically implements IModifiableType so you can intercept/replace method calls at runtime
var modifiableType = account as IModifiableType;
if (modifiableType != null)
modifiableType.MethodCallReplacementProvider = new WriteLineMethodReplacementProvider();

account.Deposit(100);

The WriteLineMethodReplacementProvider class, in turn, determines the method calls that should be intercepted at runtime:

public class WriteLineMethodReplacementProvider : IMethodReplacementProvider
{
public bool CanReplace(object host, IInvocationInfo info)
{
var declaringType = info.TargetMethod.DeclaringType;
if (declaringType != typeof(System.Console))
return false;

// We're only interested in replacing Console.WriteLine()
var targetMethod = info.TargetMethod;
return targetMethod.Name == "WriteLine";
}

public IInterceptor GetMethodReplacement(object host, IInvocationInfo info)
{
return new ConsoleInterceptor();
}
}

Choosing which methods to intercept

As you can see from the example above, this class ensures that only calls to Console.WriteLine() are ever intercepted. The ConsoleInterceptor itself is responsible for replacing and intercepting the Console.WriteLine() method itself:

public class ConsoleInterceptor : IInterceptor
{
public object Intercept(IInvocationInfo info)
{
var targetType = info.TargetMethod.DeclaringType;
var target = info.Target;
var targetMethod = info.TargetMethod;
var arguments = info.Arguments;

Console.WriteLine("Intercepted method named '{0}'", targetMethod.Name);

// Call the original WriteLine method
targetMethod.Invoke(null, arguments);

// Console.WriteLine doesn't have a return value so it's OK to return null)
return null;
}
}

The most interesting part about the code example is how LinFu.AOP adds the method call hooks without touching a single line of the source code. All of the IL rewriting is done behind the scenes so you won’t have to worry about the gory details of using an AOP framework in your legacy code. The beauty of this approach is that it allows you to intercept any method call, even if that method call is a part of the .NET base class libraries.
You can find the LinFu.AOP.Examples library here at Github.
NOTE: Please intercept BCL method calls responsibly.

Beyond Duck Typing with LinFu.DynamicObject: Creating Types that can Change at Runtime

2011-04-27T02:48:00.001-07:00

A Post-Easter Egg

One of the hidden features that LinFu.DynamicObject has is the ability to dynamically add properties and methods to itself using a shared type definition at runtime. In other words, you can have two or more LinFu.DynamicObject instances share the same DynamicType, and any changes you make to that type will be propagated to all LinFu.DynamicObject instances that share that same type:

using LinFu.Reflection.Extensions;
using NUnit.Framework;

namespace LinFu.Reflection.Tests
{
[TestFixture]
public class DynamicTypeTests
{
[Test]
public void ShouldBeAbleToShareTheSameDynamicType()
{
var typeSpec = new TypeSpec() { Name = "Person" };

// Add an age property 
typeSpec.AddProperty("Age", typeof(int));

// Attach the DynamicType named 'Person' to a bunch of dynamic objects
var personType = new DynamicType(typeSpec);
var first = new DynamicObject();
var second = new DynamicObject();

first += personType;
second += personType;

// Use both objects as persons
IPerson firstPerson = first.CreateDuck<IPerson>();
IPerson secondPerson = second.CreateDuck<IPerson>();

firstPerson.Age = 18;
secondPerson.Age = 21;

Assert.AreEqual(18, firstPerson.Age);
Assert.AreEqual(21, secondPerson.Age);

// Change the type so that it supports the INameable interface
typeSpec.AddProperty("Name", typeof(string));
INameable firstNameable = first.CreateDuck<INameable>();
INameable secondNameable = second.CreateDuck<INameable>();

firstNameable.Name = "Foo";
secondNameable.Name = "Bar";

Assert.AreEqual("Foo", firstNameable.Name);
Assert.AreEqual("Bar", secondNameable.Name);
}
}
}

Evolving Ducks

Most of the code above is self-explanatory, and the most interesting part about this code is the fact that it has two DynamicObject instances that share the same DynamicType instance. Once the Age property was added to the DynamicType definition, both first and second DynamicObjects automatically ‘inherited’ the additional Age property that was added to the DynamicType at runtime. Another interesting piece of code was the duck typing call to the IPerson interface, which wasn’t possible until after the Age property was added:

// Use both objects as persons
IPerson firstPerson = first.CreateDuck();
IPerson secondPerson = second.CreateDuck();

firstPerson.Age = 18;
secondPerson.Age = 21;

Assert.AreEqual(18, firstPerson.Age);
Assert.AreEqual(21, secondPerson.Age);

As you can see from the example above, LinFu.DynamicObject is smart enough to change its definition every time the attached DynamicType definition changes, and that’s why it was also able to duck type itself to the INameable interface:

// Change the type so that it supports the INameable interface // Change the type so that it supports the INameable interface
            typeSpec.AddProperty("Name", typeof(string));
            INameable firstNameable = first.CreateDuck<INameable>();
            INameable secondNameable = second.CreateDuck<INameable>();

            firstNameable.Name = "Foo";
            secondNameable.Name = "Bar";

            Assert.AreEqual("Foo", firstNameable.Name);
            Assert.AreEqual("Bar", secondNameable.Name);

Pretty straightforward, isn't it? (LinFu.DynamicObject has had this feature for well over 4 years, but I never got around to publishing it until now). Enjoy!

Duck Typing with LinFu & C# 4.0’s Dynamic Keyword

2011-04-25T17:40:00.001-07:00

The Lame Duck

When C# 4.0 came out with the dynamic keyword, I was pretty excited over the prospect of having Ruby-like features finally being baked in to the C# language itself, but as one of my twitter followers and friends pointed out in one of their posts from a few years ago, C# 4.0 still lacks duck typing support, and the .NET BCL doesn’t seem to have anything that could do something similar to the following code:

public interface ICanAdd
{
int Add(int a, int b);
}
public class SomethingThatAdds
{
private ICanAdd _adder;
public SomethingThatAdds(ICanAdd adder)
{
_adder = adder;
}
public int FirstNumber { get; set; }
public int SecondNumber { get; set; }
public int AddNumbers()
{
return _adder.Add(FirstNumber, SecondNumber);
}
}

There has to be some way to construct an object at runtime and map it to an ICanAdd interface, but the problem is that the current .NET Base Class Libraries don’t seem to have a solution for this problem. As Dave Tchepak pointed out in his post, the following dynamic code will fail miserably at runtime:

public class Dynamic : DynamicObject
{
Dictionary<String, object> members = new Dictionary<string, object>();
public override bool TrySetMember(SetMemberBinder binder, object value)
{
members[binder.Name] = value;
return true;
}
public override bool TryGetMember(GetMemberBinder binder, out object result)
{
return members.TryGetValue(binder.Name, out result);
}
}
// ..and the test would look like:
[Test]
public void CannotUseDynamicAdderForAnythingUseful()
{
dynamic adder = new Dynamic();
adder.Add = new Func<int, int, int>((first, second) => first + second);
var somethingThatCanAdd = new SomethingThatAdds(adder); /* Fails here at runtime */
somethingThatCanAdd.FirstNumber = 10;
somethingThatCanAdd.SecondNumber = 20;
Assert.That(somethingThatCanAdd.AddNumbers(), Is.EqualTo(30));
}

The problem is that the runtime isn’t smart enough to figure out that there has to be a duck-typing cast to the ICanAdd interface in order to use the SomethingThatCanAdd class, and that’s where LinFu’s DynamicObject comes in handy.

If it walks and quacks like a duck, then it’s all good

LinFu.DynamicObject is flexible enough that it can let you build object instances at runtime and then ‘strongly’ duck type those object instances to any interface that matches the intended duck type. In this case, we need to find a way to build up something that can map to an ICanAdd interface instance so that it can be used by the SomethingThatAdds class:

[Test]
public void CanCreateADynamicAdder()
{
var adder = new DynamicObject();
CustomDelegate addBody = delegate(object[] args)
{
int a = (int)args[0];
int b = (int)args[1];
return a + b;
};
// Map LinFu's DynamicObject to an ICanAdd interface
var linfuDynamicObject = new DynamicObject(new object());
var returnType = typeof(int);
var parameterTypes = new Type[] { typeof(int), typeof(int) };
linfuDynamicObject.AddMethod("Add", addBody, returnType, parameterTypes);
// If it looks like a duck...
Assert.IsTrue(linfuDynamicObject.LooksLike<ICanAdd>());
// ...then it must be a duck, right?
var somethingThatCanAdd = new SomethingThatAdds(adder.CreateDuck<ICanAdd>());
somethingThatCanAdd.FirstNumber = 10;
somethingThatCanAdd.SecondNumber = 20;
Assert.AreEqual(somethingThatCanAdd.AddNumbers(), 30);
}

 The call to the DynamicObject.CreateDuck() method does all the heavy lifting for you so you don’t have to worry about the details of how to make the object behave like a duck. It just works, and that’s the power that LinFu offers.

(EDIT: You can grab the source code and examples for LinFu.DynamicObject here at Github)

Technorati Tags: linfu,dynamicobject,csharp4

A CQRS and an AOP expert walk into an Oredev bar…

2011-04-24T04:28:00.001-07:00

A mind-bending experience

Back in November 2010 of last year, I remember that a stranger walked up to me at the Green Lion Inn Bar after the Oredev conference and told me that my notion of aspects, and of object-oriented design was actually a limited version of some of the message passing capabilities of some old language named Smalltalk.

He asked me to imagine for a moment that everything in OOD is a message. In original OO terminology, he said, there were methods, and messages. Whenever you call a method (in today’s terminology), what you are implicitly doing is sending a message to an object telling it to execute the code associated with that message (the method).

For me, the concept of methods executing as a result of implicitly sent messages seemed fairly straightforward, but the discussion took an interesting turn.

He said, “Imagine that these messages can be sent from anywhere. They can be running within the same process, running on your machine, or they can even be coming from a machine that is located halfway across the world.”

The concept of Remote Procedure Calls wasn’t anything new—but the next thing he said piqued my interest.

“If every method is merely a message to be sent, then any method call can be remoted [if you rewrite it with IL].”

In effect, what Greg was proposing was to create a messaging system that was so granular that one could transparently take any method call on any given machine and have it execute on another machine or process without modifying the original source code. In theory, one could use such a system to split a single process so that it runs parallel on multiple machines, all without modifying the original source code.

In other words, he was proposing automatic parallelization of any application using AOP, and IL rewriting.

Needless to say, my jaw hit the floor, and I was left speechless.

NDC Talk Preview: “Ten Simple Rules for Rewriting IL on the Common Language Runtime”

2011-04-24T03:29:00.001-07:00

Introduction

One of the things that frustrated me when I first started learning how to write (and rewrite) IL back in the early 2000’s was the fact that there were very few practical examples on how to do anything useful with IL. In fact, the only reliable learning tools that were available around at the time was PEVerify.exe, and IL disassembler. In the six to seven years since I first started writing/rewriting IL, I often asked myself what it would take to write a useful IL tutorial that would be easy enough for someone with a minimal C# background to learn, and yet be informative enough that it would be useful to someone who has written an AOP framework of their own.

Fast forward to 2011

Over the years, I have learned some really hard lessons about IL, and now that I’ll be speaking at NDC 2011, it will be the first time that I will get to share what I have learned with the .NET community. Make no mistake—IL writing can be a “mystery wrapped in frustration containing an enigma”, but the good news is that I have been through many of those pitfalls, and now I can help other developers understand what’s going on when those errors occur, and I can even show you how to fix those errors.

Ten Lessons Learned

In fact, there are ten basic principles that you can follow that will make it easier for you to understand and work with IL writing/rewriting. These principles are:

Rule #1: If you don’t understand IL, then learn from the C# compiler
Rule #2: Always keep the stack in a balanced state; One push = one pop
Rule #3: Don’t forget to explicitly box/unbox your types
Rule #4: PEVerify.exe can be your best friend and worst enemy at the same time
Rule #5: Use Console.WriteLine() to triangulate errors in your IL at runtime; Use it well, and use it often
Rule #6: GOTO statements in IL are a Good Thing™
Rule #7: Emit as few IL instructions as possible
Rule #8: Almost anything can be modified, including sealed classes and final methods
Rule #9: You can replace any given method call as long as you replace it with a method that leaves the stack in the same state
Rule #10: IL can be learned like any other programming language; practice makes perfect.

Many of these lessons learned are fairly straightforward, while some principles will require a bit more explanation during the talk. No matter what your level of experience in IL might be, I guarantee that this is one informative session that you won’t want to miss. Stay tuned, and I’ll see you all at NDC 2011!

I’m joining Readify in Sydney, Australia!

2011-04-22T19:45:00.001-07:00

Way more than the average job

After a year of working for an investment bank in Hong Kong, I realized that I needed a job more meaningful than just churning out number-crunching apps for people that I would never meet or rarely ever see. Opportunity, as the saying goes, rarely ever knocks twice at a person’s door, and when Readify said that they would let me work for them after I turned them down last year to go to Hong Kong, I knew that this opportunity would never come again, and I decided to take it. It’s not every day that one gets a chance to work with some of the best developers in the .NET community, and I am humbled by the fact that I will get the chance to work with them.

Hong Kong, in Retrospect

In hindsight, living in Hong Kong has been a very comfortable experience. The city is relatively small, it has an excellent public transportation system, and you can practically get anything you want within a few keystrokes on your keyboard, a call from your mobile phone, or just by going to Mongkok to shop for the latest gadgets. For me, the problem wasn’t living in the city per se—it was the idea of having to indefinitely work on the same business apps within the same business domain for years upon years on end. Working in investment banking IT has certainly been a lucrative venture for me, but I wanted a role that would let me go out and help other clients and developers be more effective at what they do. At the same time, I wanted to work within the confines of a relatively smaller and close-knit company that gave their people more control over how they work rather than having them go through so many processes because of legal restrictions or mandated institutional regulations.

To Sydney, and Beyond

Shortly after my upcoming talk at NDC 2011, I’ll be packing all my things and I’ll be moving to Sydney, Australia to work with the folks at Readify. There’s no telling what the future holds for me, but if this job opportunity is any indication, then the future looks bright indeed.

Speaking about “Ten Simple Rules for Rewriting IL on the Common Language Runtime” at NDC 2011

2011-04-22T01:21:00.001-07:00

Red or Blue

Have you ever wondered what happens under the hood of an AOP framework? Have you ever tried writing IL, only to get hit by an unintelligible wall of PEVerify.exe errors?

Learning how to (re)write IL can be hard, but in this session, I will show you some techniques for rewriting almost any .NET assembly with the least amount of effort and the most minimum amount of frustration possible. The art of rewriting IL will give you the ability to change programs as if you (the developer) are the compiler itself. With IL rewriting, you can add, remove, replace, unseal, and redirect method calls from any type. You can change almost any method you can possibly imagine, including methods in third party libraries that don’t have any source code publicly available. The possibilities are endless, and there’s a whole other hidden world that goes on when you compile your code into IL using your favorite .NET language, and this talk will show you just how different things are once take the red pill.

Join me at NDC 2011 in Oslo at 11:40AM-12:40PM on Track 5, and I’ll show you just how deep that rabbit hole really goes.

Øredev 2010, Part 1

2010-11-15T05:54:00.001-08:00

Background

Aside from becoming a great programmer, one of my lifelong dreams has always been to visit Sweden and be able to see everything that its cities have to offer. That dream finally came true last week when my employers gave me the whole week off so that I can attend the Øredev conference in Malmo, Sweden.

There were so many great things that went on during that conference, and if I had to summarize it in a single word, I would call it “amazing”, and if you’re looking for a more detailed summary, here we go:

Day Zero - Old world architecture, fine dining, and bloody gooses

After a quick round of introductions at Magnus Mårtensson's place, everyone walked over to the Malmo City Hall for the Speaker’s dinner. This place was huge, and according to some historians, it was the place where the Swedes celebrated victory over the Danish invaders that were trying to reconquer the southern region of Skane (the area now known as Malmo) back in the 1700s. It was the first time that I’ve ever seen such a place, and suffice to say, I was impressed.

The building interior was ornate with paintings of its former Danish princes and rulers, and the far end of the Council Room had images of its Swedish victors. The deputy mayor of the City of Malmo stood in front of all the attendees and welcomed us to the city. I watched as everyone lifted their champagne glasses to toast the event, and at first, I thought that we were just going to stand around in the Council Room and have a cocktail party. Ten minutes later, they escorted us into a huge dining hall, and the surroundings were like something out of an old world fairy tale.

After everyone found their seats among the various open tables, the waiters started serving us various types of white and red wines. Everything seemed normal up to that point, until the waiters served this one mysterious bowl of soup:

At first, I thought it was some bowl of chocolate-flavored syrup. After all, as I naively told myself, the Swedes must be known for their chocolate. As it turns out, it was the Swiss (not the Swedes) that were known for their chocolate, and that “special” soup was actually a bowl that was chalk full of goose blood. When I asked the waiter what was in the bowl, he just gave me a weird look and said, “they didn’t tell you what was in the bowl?”

I just shook my head and waved the bowl away, and if weren’t for my vegetarian tendencies, I probably would have become an avian vampire. After picking and eating the meatless option (which was the lobster soup), I went around the room and took a few pictures of some of the notable speakers that were at the conference:

Center: Jeremy Miller, aka “The Shade Tree Developer”

What surprised me was that many of the developers that I had been reading about for many years were sitting right there in front of me in that dining hall. They were no longer just some prestigious names on a random blog post on a programmer site. They were there, en vivo, and it was nice to finally be able to match a face to each one of their names.

Center: Roy Osherove, author of “The Art of Unit Testing in .NET”, and Hadi Hariri, Tech Evangelist at Jetbrains

For the most part, the rest of the dinner was filled with toasts and speeches from the Øredev organizers. Overall, I’d say that the food was excellent, and as introductory dinners go, it was filled with lots of people getting to know each other over bleeding gooses. For me, it was remarkable for its attendees, but relatively unremarkable for the dinner chatter.

Things didn’t get interesting until we all left Malmo City Hall and went to the Green Lion Inn. After spending about an hour talking to Hadi (Hariri) about emergent refactoring techniques, he said that he had to get some sleep because he had to be at the Jetbrains booth very early by the next morning, so I said goodbye to him, and he left.

I was tired too, and I figured that I should go back to my room and get some rest. My internal body clock was seven hours ahead of my physical location, and I was headed for the door until some stranger approached me and told me that he wanted to talk to me about AOP. The two-hour conversation about AOP that soon followed seriously changed the way I saw AOP, and that stranger was no ordinary stranger.

It was Greg Young, and he blew me away with what he had to say.

…to be continued

Announcement: LinFu is now on Github!

2010-03-07T03:14:00.000-08:00

LinFu has been my obsession for the better part of six years, and despite all its features, almost every patch, fix, and feature request has been handled by one and only one person--me. After three years, the codebase itself has become quite mature, and I realize that there will be some point where I have to completely open this project up to the rest of the community so that it can grow and this is just the first step.

Today, I'm happy to announce that all of LinFu version 2.0 has been moved to Github (under the same LGPL license), and you can fork it as much as you want. I will still actively maintain it (just as I maintained it on google code), but the difference is that anyone here can make changes to the project and I will be more than happy to accept pull requests.

No man is an island, and now it's time to swim in the sea of possibilities.

Happy forking, and let me know if you come up with anything interesting :)

Introducing Hiro.Functors, and Making Hiro a Dynamic Container

2009-12-24T18:02:00.000-08:00

One of the more salient criticisms that I've often heard about Hiro is the fact that for the most part, the containers that Hiro creates are static and cannot be modified once they have already been compiled and instantiated. There might even be cases where you might have to have a Hiro-compiled container return an existing service instance, and that service instance (in turn) might not be available when the container is first compiled. For example, let's assume that you have an existing service instance of class type Foo that implements the IFoo interface:

public interface IFoo
{
// ...
}

public class Foo : IFoo
{
// ...
}

Let's also assume that Foo is some sort of long running service that must be returned every time you ask for an IFoo instance from a Hiro-compiled container. In previous revisions of Hiro, you probably could have registered the IFoo service as a singleton using the following code:

var map = new DependencyMap();
map.AddSingletonService();

var container = map.CreateContainer();

// ..Use the container code here

The problem with the previous code above is that you can't use it if the Foo instance has already created before the container instance has been compiled. Since the hypothetical Foo service is a long-running service that already exists before each container is compiled, there doesn't seem to be any way to make a DependencyMap return an existing object instance--that is, until now. This is where Hiro.Functors comes to the rescue:

// For the sake of simplicity, let's assume that Foo has already been instantiated..
var existingFooInstance = new Foo();

// Define the factory functor
Func<IMicroContainer, object> makeFoo =>existingFooInstance;

var map = new DependencyMap();
map.AddService(typeof(IFoo), makeFoo);
var container = map.CreateContainer();

// Get the foo service; The makeFoo functor will be called here
var actualFoo = container.GetInstance();

// This will evaluate to true
Assert.AreSame(existingFooInstance, actualFoo);

As you can see from the code above, the Hiro.Functors library extends Hiro so that you can use C#'s native lambda syntax to add your own custom factory methods to any Hiro-compiled container. A single call to the additional DependencyMap.AddService(yourServiceType, yourFunctor) is all you need to convert Hiro from a static container to a dynamic container without sacrificing speed for flexibility. It's just that simple.

I prefer to call Hiro the "blue collar" IOC container framework, and Hiro.Functors is just another step in helping you (the end-user developer) get the job done with as little drama as possible in the fewest amount of steps possible. While there's definitely nothing revolutionary about this tiny release, I think there's plenty to be said about having an IOC container that gets in and does the job using the flattest learning curve possible, and that's exactly what Hiro offers.

While I can't promise my readers that I'll change the world with revolutionary tools, what I will promise them is that my tools will be the simplest tools that they can possibly use so that they'll be able to meet their deadlines on time and make it home early for holidays like today. Hiro is one such tool, and if you ever run into any problems with it, I'm only a patch and an email away. Happy holidays, everyone!

(Note: You can get Hiro.Functors here)

Creating Per-Session Services with Hiro

2009-09-09T16:01:00.000-07:00

Over the past week, I've had a few people ask me how they can use Hiro to create services that are instantiated once per web session. Ideally, Hiro should be able to do something like this:



// Instantiate the IFoo service
var context = HttpContext.Current;

if (context.Session["SomeFooKey"] == null)
  context.Session["SomeFookey"] = container.GetInstance<IFoo>();

return (IFoo)context.Session["SomeFooKey"];

The code itself is pretty simple, but the problem is that this can get quite cumbersome if you have more than a few services that need to be stored in the Session object. There has to be some way to do this with Hiro using a single method call, and indeed, Hiro makes creating per-session services just as equally effortless:


// Register the Foo service into the DependencyMap
var map = new DependencyMap();
map.AddPerSessionService(typeof(IFoo), typeof(Foo));

// Compile the container
var container = map.CreateContainer();

var foo = container.GetInstance<IFoo>();

// ...use the IFoo per-session service here (just like any other service)

As you can see from the example above, Hiro abstracted away the details of having to deal with caching your services into a Session object. In fact, all you have to do to add per-session services to your dependency maps is to use the AddPerSessionService extension method, compile your container and use it like any other Hiro-compiled container. It's just that simple.

NOTE: You can download the Hiro.Web extensions (including the per-session service support extension method) here.

Introducing Hiro, the World's Fastest IOC Container, Part III: The Container Itself

2009-07-27T15:57:00.000-07:00

Introduction

In this final installment of the Hiro series, I'll show you just how ridiculously simple it is to use Hiro in your own applications without sacrificing speed for simplicity. I'll also show you how you can use Hiro's registration conventions so that you will never have to worry about managing any external configuration files or declare any external attributes on your types just so you can get your types registered into a service container.

Simply Fast, and Simply Simple

As I mentioned in my previous posts, Hiro lacks many of the "fat" features that you would normally associate with other IOC containers (including LinFu). At first, that might seem like a disadvantage for potential Hiro users, but it also implies that you won't have to waste any time trying to understand any IOC container features that you probably will never use in most of your applications. Instead, Hiro focuses on doing three things:

Determine the list of available services from any given assembly.
Registering those services into a container
Ensuring that the container can create the services that you registered.

Unlike other IOC containers, Hiro doesn't need you to use fluent interfaces or attributes to register your types into a container. You don't even need lambda functions or an external XML configuration file to get your services up and running with Hiro. Instead, Hiro uses Convention over Configuration semantics that let you register your services with only a few lines of code. Here's an example:


// Use the loader to scan the target assembly
// for services
var loader = new DependencyMapLoader();

// The loader will handle all the details of loading
// the services into the container for you
DependencyMap map = loader.LoadFromBaseDirectory("SampleDomain.dll");
var container = map.CreateContainer();

// (Do something useful with the container here)
var greeter = container.GetInstance<IGreeter>();

// ...

"Convention over...what?"

At first glance, it's hard to believe that Hiro can load all the services from a given assembly (or a set of assemblies) using only the code that was given in the previous example. After all, any given service can have nearly an infinite amount of constructor and property injection dependencies, and given the sheer complexity of this task, there must be a set of rules that Hiro follows that somehow makes the registration happen "automagically". At the same time, there might be some end-user developers out there that might want to have strict control over the actual services that will be registered into the compiled container. In other words, how does Hiro know exactly what to register and still be able let users control what gets registered into a compiled container?

A Few Rules Go A Long Way

Now the reason why Hiro can do so much in so few lines of code is because that it implements a few conventions that typical IOC container users would follow when registering their own types. As long as users follow those conventions, they will never have to worry about manually registering any of their service types with Hiro. For example, let's assume that you had this particular service type declared in a single assembly:

  
  public interface IGreeter
  {
      void Greet(string name);
  }

Let's also assume that you have three concrete classes that implement the same IGreeter interface:

  
  public class GermanGreeter : IGreeter
  {
      public void Greet(string name)
      {
          Console.WriteLine("German: Hallo, {0}!!");
      }
  }

  public class FrenchGreeter : IGreeter
  {
      public void Greet(string name)
      {
          Console.WriteLine("French: Bonjour, {0}!", name);
      }
  }

  public class Greeter : IGreeter
  {
      public void Greet(string name)
      {
          Console.WriteLine("English: Hello, {0}!", name);
      }
  }

"Just give me the default service, please!"

Based on the examples above, it probably didn't take you very long to infer that the Greeter class is the default implementation for the IGreeter interface. Furthermore, it's probably safe to assume that a default implementation exists if you have an interface named IYourService and if you already have a concrete class named YourService that implements that particular service type. Hiro follows the same convention, so calling container.GetInstance on an IGreeter type will yield a Greeter instance:

  

// Load the sample assembly
var loader = new DependencyMapLoader();
DependencyMap map = loader.LoadFromBaseDirectory("SampleDomain.dll");
var container = map.CreateContainer();

// Get the default implementation
var greeter = container.GetInstance<IGreeter>();

// Determine the actual type that implements the IGreeter interface
var greeterType = greeter.GetType();

// This expression will return true
Console.WriteLine(greeterType == typeof(Greeter));

As you can see, the example above is fairly self-explanatory. The DependencyMapLoader class will automatically determine that the Greeter type is the default implementation for the IGreeter interface and register it into the DependencyMap. Of course, this approach assumes that you have a class with a type name that matches the service type name; however, there might be cases where you have multiple classes that implement the same interface but don't follow this naming convention. For example, if I have the FrenchGreeter and a GermanGreeter class but don't have a default Greeter class, how does Hiro determine which implementation should be used as the default implementation type?

When All Else Fails, Use the Alphabet

The answer is that by default, Hiro will pick the first implementation type from a list of service implementations that have been sorted alphabetically by type name. In this case, Hiro will choose the FrenchGreeter as the default IGreeter implementation since the FrenchGreeter class name alphabetically appears before the GermanGreeter class name:


// ...

// Get the default implementation
var greeter = container.GetInstance<IGreeter>();

// Determine the actual type that implements the IGreeter interface
var greeterType = greeter.GetType();

// This expression will return true since
// the FrenchGreeter type appears before the GermanGreeter type
Console.WriteLine(greeterType == typeof(FrenchGreeter));

While this approach might be useful for determining (and thus accessing) a default service implementation, there has to be a way to access the other concrete IGreeter implementations that reside in the compiled container. As it turns out, Hiro makes this process just as equally effortless:


// Get the French and German greeters
var frenchGreeter = container.GetInstance<IGreeter>("FrenchGreeter");
var germanGreeter = container.GetInstance<IGreeter>("GermanGreeter");

By default, Hiro registers each service implementation using the class name of each concrete service type. In order to access a particular service implementation, all you need to do is pass the name of the implementing type in the container.GetInstance<T> call, and the container will instantiate the corresponding type for you.

Using Constructor Injection and Property Injection

Now that we have an idea of how Hiro registers service types into a container, the next thing that you might be wondering about is exactly how Hiro injects dependencies into constructors and properties. For example, if I have a class named GreeterHost that takes one IGreeter dependency in its constructor, how do I tell Hiro to use that constructor instead of the default constructor? Let's take a look at the GreeterHost class:


public class GreeterHost
{
  public GreeterHost ()
  {
  }
  public GreeterHost(IGreeter greeter)
  {
     // Do something useful here
  }

  // ...
}

Let's also assume that I manually registered the GreeterHost class with the DependencyMap using the DependencyMap.AddService method. Here's how you get Hiro to perform constructor injection:



// Manually add the GreeterHost to the dependency map
var map = new DependencyMap();
map.AddService<GreeterHost, GreeterHost>();

// Manually add an IGreeter service so that Hiro uses the constructor
// with the IGreeter parameter
map.AddService<IGreeter, Greeter>();

// Compile the container
var container = map.CreateContainer();

// Create the GreeterHost. Hiro will automatically
// inject the IGreeter implementation into the constructor
var greeterHost = container.GetInstance<GreeterHost>();

As you can see from the example above, Hiro automatically used the contents of the dependency map to determine which constructor should be used for instantiating the GreeterHost type. The only thing that I needed to do to perform constructor injection was to make sure that the IGreeter service type was available in the dependency map once the container was compiled. The compiled container, in turn, used the IGreeter dependency to call the correct GreeterHost constructor.

Singletons Galore

NOTE: If you prefer to have your Greeter type registered as a singleton in the dependency map, however, here's how you do it:


// Manually add an IGreeter service so that Hiro uses the constructor
// with the IGreeter parameter
map.AddSingletonService<IGreeter, Greeter>();

Constructor, Inject Thyself

The best part about the constructor injection example with Hiro is the fact that it handles all the gory details of performing constructor injection for you in the most minimal lines of code possible. In this case, the only convention that you have to follow is to make sure that the dependency map contains all the necessary services for Hiro to call the appropriate constructor. What makes this even more interesting is that Hiro can perform automatic constructor injection with constructors that have any arbitrary number of constructor arguments. In other words, if the DependencyMap instance has the constructor dependency, then Hiro can handle the injection.

Property, Inject Thyself Too

For the most part, Hiro's property injection follows some of the same conventions as constructor injection. Much like constructor injection, the only thing you need to do to use property injection with Hiro is to make sure that services required by the target property are already registered with the dependency map once the container is compiled. For example, let's assume that GreeterHost class as an IGreeterProperty named CurrentGreeter:


public class GreeterHost
{
  public IGreeter CurrentGreeter
  {
     get;set;     
  }
}

Here's how you set up Hiro's dependency map to perform property injection:


// Manually add the GreeterHost to the dependency map
var map = new DependencyMap();
map.AddService<GreeterHost, GreeterHost>();

// Manually add an IGreeter service so that Hiro uses the constructor
// with the IGreeter parameter
map.AddService<IGreeter, Greeter>();

The first thing that you might notice is that the setup code for property injection and constructor injection are both identical to each other. In fact, you could even say that I just "copy & pasted" the example from previous examples in this article. Indeed, that was intentional, and the point here is that are only two simple things that you need to do to make Hiro automatically perform property injection on your types:

Ensure that the service types that your properties require are registered with the dependency map.
Ensure that the properties that will be injected are not read-only properties.

In other words, Hiro's property injection conventions follow one of the most basic dependency injection conventions of all:

If you don't want Hiro to inject dependencies into your target property, then make sure the property is a read-only property or the property type doesn't exist in the container as a service type.

All you need to do to disable property injection for the GreeterHost is to prevent a default IGreeter service from ever being registered into the dependency map. You can do this by either constructing the dependency map by hand, or you can attach a service filter to the DependencyMapLoader so that it avoids loading a default IGreeter service into the resulting dependency map:


var loader = new DependencyMapLoader();

// Make sure that no default service is loaded for the IGreeter interface
loader.ServiceFilter = service=>service.ServiceType != typeof(IGreeter) && string.IsNullOrEmpty(service.ServiceName);

As you can see from the example above, all you need to do to prevent the DependencyMapLoader from registering services is use a simple lambda function, and it can't get any simpler than that.

Next, here's the call that will construct the GreeterHost and perform the property injection operation if you still have the required dependency inside the container:


// This is the only method call you need
// to do property injection
var greeterHost = container.GetInstance<GreeterHost>();

// ...

Fortunately for the end-user developer, the GetInstance method that performs the constructor injection is also the same method that will perform all property injection operations. Hiro uses these simple conventions to make developers' lives easier, and if it can help at least one person out there write better code, then I consider this project to be a success.

--

You can download Hiro from here.
You can also click here to download the Hiro example solution.

NDepend Review

2009-07-16T18:47:00.000-07:00

The Quick & Dirty

There have been a lot of good reviews written for NDepend, so for the sake of efficiency, I'll get straight to the point: NDepend is an amazing tool. It lets you graphically inspect your assemblies and it lets you pinpoint the spots in your code base that need refactoring.

So would I recommend buying NDepend Professional? Yes.

Is there something that I didn't like about NDepend that I think the users should know about? Yes, and that's exactly what I'll talk about.

"So what's not to like about NDepend?"

My only problem with NDepend is that its CQL query engine can only be accessed from the Visual NDepend application. NDepend does let you embed CQL attributes in your applications, but the problem is that I shouldn't have to force each one of my applications to have a dependency on NDepend just because I want to have some code metrics calculations in my build process. Of course, there are a few ways that I can work around that limitation, but the point is that I shouldn't have to make a workaround for something that should have been there in the first place.

In other words, what NDepend sorely needs right now is a publicly-accessible CQL engine API. If NDepend is truly a tool built by developers for developers, then it should have an API that other developers can use to analyze their applications. It's not enough to throw them a rudimentary command-line tool that spits out code metrics in XML--that pretty much leaves developers to write code against the "shadow" of the CQL API rather than write against the CQL API itself, and for me, that just doesn't quite cut it.

Don't get me wrong--the Visual NDepend winforms application is an awesome app--but I'd rather be able to filter through all that information using a single API call rather than have to manually sift through several windows just to find the information I need.

Now the reason why I'm harping so much about the lack of a public CQL API is that my company uses NDepend Professional in its command line builds to ensure that our builds fail when the Cyclomatic Complexity score exceeds 2.5 in any of our projects. The problem is that we want our code quality inspections to be completely automated, and we can't do that unless we have access to the CQL API and can generate CQL queries at runtime. The maximum Cyclomatic Complexity score might prevent our developers from writing complicated code, but there's far more to code inspections than just looking at a single score. What we need is a way to look deeper into the quality of our code base using the hypothetical CQL API with the same ease that Visual NDepend users can browse through their code.

So in the end, I still recommend NDepend Pro as definite buy, but it still lacks a few key features that would make me give Patrick Smacchia's tool the gushing review that other bloggers have given it in their respective reviews. Overall, it's definitely a great tool, but it's not without a few shortcomings.

[Public Disclosure: Thanks to Patrick Smacchia for providing me with a free NDepend Pro license for this review.]

Introducing Hiro, the World's Fastest IOC Container, Part II: The Little Feature Set That Could

2009-04-15T16:06:00.000-07:00

The Art of Lean

Now that everyone knows just how fast Hiro can be, the next question you might be asking yourself is, "What features will it support?"

The simplest answer that I can give is that Hiro is that it will implement as little features as possible--in fact, Hiro will implement so little features that it might turn away your traditional "dynamic" IOC user. Here's the features that Hiro will implement:

-Named/Anonymous Static Component Registration. This means that you'll be able to register your services using a service name, service type, and the implementing type.

-Convention Over Configuration for Registration and Injection.. In addition to its support for programmatic registration, Hiro will be able to scan your assemblies and automatically infer:

The list of available services
The list of concrete types that implement those services
The list of properties that can be injected
The constructors that will be used for constructor injection
The services that will be injected into each parameter during a constructor injection call.

The most interesting part about this is the amount of work that will take to do this sort of registration. Take a look at this example:


          var loader = new DependencyMapLoader();
          var map = loader.LoadFrom(AppDomain.CurrentDomain.BaseDirectory, "Yourlibrary.dll");

          IContainerCompiler compiler = new ContainerCompiler();
          var microContainer = compiler.Compile(map);

          // Do something with the container here

Believe it or not, this is the only code that you need to use to configure the dependencies for any assembly of any given size. What makes this even more interesting is the fact that all of this is done statically at (container) compile time, not runtime. This means that unlike the current generation of IOC containers, Hiro will not waste any time trying to rediscover your configuration, and based on the benchmark results from my previous post, the performance numbers are nothing short of being dramatically one-sided.

-Transient/Singleton instances. Aside from performance, however, Hiro has to be able to create both Transient (that is, plain old object instances created with the New operator) and Singleton instances.

-Property/Constructor Injection. Hiro will implement both property and constructor injection by default. What makes this even more interesting is that like everything else with Hiro, all property and constructor injection calls will all be precompiled into IL, meaning that there will be no performance issues when using Hiro.

-Stateless. Each Hiro-compiled container instance will not have any private local data (or even shared data) that will distinguish it from another compiled container of the same type. This means that you can scale Hiro's compiled containers across multiple cores AND multiple threads without using a single semaphore, mutex, or lock statement (in C#).

"But wait, your container isn't a REAL container until you implement feature X!"

Some would argue that Hiro would have to implement a minimum "baseline" feature set in order to be considered a "commercial" quality IOC container. However, my counterargument there is that it's this same "fat feature" mindset that got these IOC containers (including LinFu) into this speed problem in the first place. Secondly, if you're experienced enough about IOC to understand the significance of what Hiro does, then it's safe to assume that you're a user that falls into at least one of the following categories:

You've probably written at least one IOC container framework, or
You already are comfortable with an existing IOC container framework (such as Castle, Ninject, AutoFac, Unity, StructureMap, LinFu, etc) and you know enough to customize it to your needs.

Assuming that you're an IOC container author, it would be pointless for me to implement something in Hiro that you've probably rolled into your own framework, and given that you're skilled enough to write your own framework, it would be practically trivial for you to plug Hiro into your own framework and reap the performance benefits, and there's clearly no reason to reinvent the wheel here if you somehow did a better job than I did in implementing "feature X".

Now, if you think you're a user that falls into the second category, there's a good chance that you've pretty much decided to stick to the favorite framework of your choice, and like the other IOC container authors, there's really nothing that I can do for you unless you decide to plug in Hiro into your favorite container.

So between these two types of users, who do you think Hiro is written for?

Here's my answer: Neither one of them. Hiro is written for the average developer who wants to get started with an IOC container and doesn't have time to "geek out" over the latest and greatest features of an IOC container framework. Given that there are probably far better IOC container developers than myself, I've pretty much decided to skip the "my container is better than your container" religious wars and focus on what really matters: the end users.

The Pareto Pleasure Principle

Hiro doesn't need to implement 80% of the expected features of an IOC container in order to be useful--instead, it only has to implement the other 20% of the overall features that (in my opinion) people will actually use. In the end, if I can help those people get their jobs done in the simplest possible way without forcing them to wade through the "awesomeness" of my framework, then I would call Hiro a success, and at the end of the day, that's really all that matters.

Introducing Hiro, the World's Fastest IOC Container, Part I: Design Diary

2009-04-07T16:42:00.000-07:00

Introduction

Have you ever had one of those moments where someone told you that your work sucked, and it inspired you to create something better? About a month ago,Alex Simkin sent me a message on the CodeProject forums for one of my articles saying that LinFu ranked second to last in performance among all the other containers, and that he was willing to show me the benchmark code that produced those numbers.

Eating the Humble Pie

Unfortunately, Alex was correct. Despite all of its features, LinFu landed a spot near the bottom of the pack, and needless to say, there had to be a better way to design a container so that it wouldn't have these bottlenecks.

"But...but...my container is dynamic and it's flexible!"

As an IOC container author myself, I've probably given that same excuse a dozen times over whenever someone complained that my framework was too slow. I never realized that the flexibility that I so touted in all my IOC articles was the same cause for all my performance headaches. Indeed, there had to be some way to improve these numbers, and at first, I thought adding more dynamic IL generation would solve the problem. After all, Lightweight Code Generation with DynamicMethod seems to be the trend nowadays among the other frameworks like Ninject, and that makes their code run faster, right?

Once again, I was wrong. DynamicMethods didn't make much of a performance impact because Ninject (which reportedly uses a lot of LCG its code) was actually the slowest among all of the IOC containers tested in the benchmark (Sorry Nate). Of course, this doesn't mean that the DynamicMethod approach is the cause of the slowdown; what it does suggest, however, is that piling more and more reflection onto the speed problem is not the solution. In addition, there were other frameworks in that benchmark (such as Funq) that didn't use any reflection at all, and yet, they still were taking significant performance hits on that benchmark. In fact, even the fastest among all the other containers--StructureMap--was still running forty-four times slower than the Plain/No Dependency Injection use case!

So the principle question is this: "Where is this bottleneck coming from, and how do I eliminate it?"

The Real Problem

As it turns out, the answer was staring me in the face all along: "It's the configuration, stupid", I thought to myself. The problem is that every major IOC container at the time of this post (such as Ninject, StructureMap, Unity, AutoFac, Castle, LinFu, etc) essentially has to trawl through each one of its dependencies just to instantiate a single service instance on every call, and practically no amount of optimization will ever compensate for the fact that they still have to "rediscover" any given part of an application's configuration in order to instantiate that one service instance. Needless to say, this rediscovery process wastes a huge amount of resources because these containers are actually "rediscovering" a configuration that (for all practical purposes) will rarely change between two successive method calls.

In layman's terms, this is akin to stopping and asking for directions at every intersection every time you want to leave your home to go to some other destination. There has to be some way to see the "whole map" and plan the trip ahead of time without having to stop for directions at every intersection. If you could plan all the possible routes on that trip ahead of time, then all the time you would have wasted asking for directions immediately vanishes.

In essence, that is what I did with Hiro. Hiro is an IOC container framework that reads the dependencies in your application ahead of time and actually compiles a custom IOC container that knows how to create those dependencies from your application itself. It uses absolutely no runtime reflection or runtime code generation, and since all your dependencies are discovered at compile time (that is, when the Hiro compiler runs), Hiro suffers zero performance penalties at runtime when instantiating your types.

Yes, you read that right: Hiro runs at 1:1 speed with a Plain/No DI configuration. Here's the results of the IOC container benchmark:

As you can see from the results above, the current crop of IOC containers (including LinFu) can only reach 2% of the speed of an application that does not use an IOC container. Now, let's take a look at Hiro's results:

If you don't believe it, then you can download and run the benchmarks yourself.

Like LinFu, Hiro is licensed under the terms of the LGPL, and you can preview the source code at this site. I'll also be starting a Hiro-contrib project, so if you want to add your own extensions, just email me at marttub@hotmail.com and I'll be more than happy to anyone who is interested. Thanks! :)

Common Service Locator Adapter for LinFu 2.0 Released!

2009-02-28T21:40:00.000-08:00

Now that LinFu.IOC 2.0 is officially out, it's time to join the rest of the IOC container pack and let users try out LinFu without tying them to any specific IOC container API. The adapter for LinFu makes it possible to use the Common Service Locator interfaces to make your applications completely container-agnostic, so if you haven't tried LinFu yet, download the adapter, and give it a shot. :)

LinFu.DynamicProxy 1.01 is now a part of NHibernate!

2008-11-06T19:34:00.000-08:00

After passing all 1500+ tests in the NHibernate test suite, LinFu.DP1 will now be an official part of the NHibernate distribution!

It's really an honor to be a part of a project that is so well-known in the .NET community, and I really want to thank the NHibernate team for giving LinFu a chance.

There were a lot of developers who shied away from LinFu DP1 for the lack of unit tests, and this proves that LinFu DP 1.0 works as advertised, regardless of whether or not the tests existed. You now have 1500+ reasons to try it out without worrying about any problems, so give it a shot, and I'll always be here to answer your questions if anything breaks.

[Disclaimer: That being said, I'm now a TDD convert and I no longer develop anything without a battery of automated unit tests--but it's still an big ego-booster to know that your code works exactly as it's supposed to work :) ]

LinFu IoC 2.0 Reaches an Important Milestone

2008-09-21T23:37:00.000-07:00

Making the Grade

After nearly two months of hard work, I am pleased to announce the impending release of LinFu.IoC v2.0! Today marks an amazing milestone in the development of LinFu's new IoC container because as of the latest build (revision 258), LinFu is the first IoC container framework to pass ALL tests in both the "MustHave" and the "ShouldHave" categories in the latest comparison between the following IoC Frameworks:

AutoFac
Castle
LinFu
Ninject
StructureMap
Spring.NET
Unity

The feature lists might vary among these IoC frameworks, but Andrey's blog post does a great job of listing some of the features that an Inversion of Control container "must" have, in addition to the features that it "should" have", and I am proud to say that LinFu is the first IoC container to successfully implement every feature described in that blog post!

What this means is that LinFu.IoC (formerly Simple.IoC) has gone from an undocumented and untested inversion of control container to a fully documented, heavily tested, feature-laden container that is capable of performing all of the tasks that one would expect from a commercial-grade inversion of control container.

In addition to the keeping the code as clean and as compact as possible, I spent countless hours ensuring that every single method, class, interface, property and enum is fully documented, regardless of whether or not that item was marked as public, internal, or private. I love my code and I love what I do, and I hope that shows in the code that I write.

The best part about all this is that LinFu's IoC container framework weighs in at only 94KB, making it the smallest IoC framework among its brethen, with the Autofac container falling at a close 110KB.

Within the next few weeks, I'll be publishing an article on CodeProject that details all the features that you can expect from LinFu.IoC 2.0, and I will time the release so that it coincides with the actual CodeProject article itself.

Meanwhile, stay tuned!

EDIT: I realize that this post is quite scant on details so if you want to dive straight into the LinFu.IoC source, you can just go here. If you want to take a look at the IoC framework comparison project, click here. The code practically speaks for itself. Enjoy!

Making Simple.IoC Even More Simple

2008-08-03T21:25:00.000-07:00

Believe it or not, the following code represents most of LinFu.IoC's functionality when managing service instances:


// The SimpleContainer will handle unnamed services
public class SimpleContainer : IContainer
{
   private readonly Dictionary _factories = new Dictionary();  

   public virtual bool SuppressErrors
   {
       get; set;
   }

   public virtual void AddFactory(Type serviceType, IFactory factory)
   {
       _factories[serviceType] = factory;
   }

   public virtual bool Contains(Type serviceType)
   {
       return _factories.ContainsKey(serviceType);
   }

   public virtual object GetService(Type serviceType)
   {
       object result = null;
       if (!_factories.ContainsKey(serviceType) && !SuppressErrors)
           throw new ServiceNotFoundException(serviceType);

       if (!_factories.ContainsKey(serviceType) && SuppressErrors)
           return null;
 
       // Use the corresponding factory
       // and create the service instance
       var factory = _factories[serviceType];
       if (factory != null)
           result = factory.CreateInstance(this);

       return result;
   }
}

// The named container will handle named services
public class NamedContainer : SimpleContainer, INamedContainer
{
   protected readonly Dictionary> _namedFactories =
       new Dictionary>();

   public virtual void AddFactory(string serviceName, Type serviceType, IFactory factory)
   {
       if (serviceName == string.Empty)
       {
           AddFactory(serviceType, factory);
           return;
       }
       // Create the entry, if necessary
       if (!_namedFactories.ContainsKey(serviceName))
           _namedFactories[serviceName] = new Dictionary();

       _namedFactories[serviceName][serviceType] = factory;      
   }

   public virtual bool Contains(string serviceName, Type serviceType)
   {
       // Use the standard IContainer.Contains(Type)
       // if the service name is blank
       if (serviceName == string.Empty)
           return Contains(serviceType);

       return _namedFactories.ContainsKey(serviceName) &&
              _namedFactories[serviceName].ContainsKey(serviceType);
   }

   public virtual object GetService(string serviceName, Type serviceType)
   {
       // Used the other GetService method if
       // the name is blank
       if (serviceName == string.Empty)
           return GetService(serviceType);

       // Determine if the service exists, and
       // suppress the errors if necessary
       bool exists = Contains(serviceName, serviceType);
       if (!exists && SuppressErrors)
           return null;

       if (!exists && SuppressErrors != true)
           throw new NamedServiceNotFoundException(serviceName, serviceType);

       var factory = _namedFactories[serviceName][serviceType];

       // Make sure that the factory exists
       if (factory == null)
           return null;

       return factory.CreateInstance(this);
   }
}

As you can see, there's nothing special about this code. Some might even scoff at it since it's too minimalistic to be useful. After all, one might say that an IoC container has far more responsibilities than just object instantiation. Ninject, for example has features such as contextual binding and method interception. Surely this isn't all there is to LinFu.IoC's features, is it?

Bend it like Ockham

Despite the varying complexity of most (if not all) IoC containers in the field, logically speaking, the code listed above is the absolute minimum amount of code necessary to separate the instantiation of a service instance from its actual client code. When you request a service instance from a given IoC container (whether it be LinFu, Ninject or countless other containers out there), there has to be some point where the container has to decide if that service instance can be created, as well as manage the lifetime of that service once it is already out of the container. As most of us IoC container developers know, there's quite a lot more to a container than just managing the lifetime of its individual services. Creating the instance is only the first step, and I'll show you how LinFu version 2's new IoC container will implement the some of the same features without sacrificing its relatively-horizontal learning curve.

The Pattern of Other Containers

Typically, these containers will use either property setter injection or constructor injection to autowire together all of the dependencies that an application might need during its lifetime. In addition, they might implement additional features such as interception, logging, and AOP. However, despite the differences in features among containers, there are two points where these features are commonly applied:

When a service is about to be created (e.g. constructor injection) or,
When a service is already instantiated (e.g. property setter injection, or interception)

This implies that a developer can add additional features to their respective IoC container simply by controlling the point where the service is going to be created as well as controlling the point where the service has been recently instantiated. In fact, if you can isolate those two points from the rest of the container, you can effectively add new features without affecting the rest of the code.

Now the reason why LinFu's IoC container can get away with such simple code is because it actually delegates its factory methods to an instance of the IFactory interface:

   public interface IFactory
{
    object CreateInstance(IContainer container);
}

LinFu's IoC container uses each factory instance to determine how a service implementation should be instantiated, and each factory instance, in turn, is responsible for managing the lifetime of each component that it creates. With that in mind, the only thing that you have to do to extend LinFu's IoC container is to control how each factory creates its object instances (such as deciding which constructor and constructor arguments to use when implementing constructor injection) and control the instances that come out of each factory.

For example, if I wanted to add interception to LinFu.IoC, all I have to do is wrap a Decorator around an IContainer (or INamedContainer) instance that wraps each service instance in a proxy:


public class ContainerDecorator : IContainer
{
  private IContainer _container;
  public ContainerDecorator(IContainer realContainer)
  {
       _container = realContainer;
  }
  // Other methods skipped for brevity
  public object GetService(Type serviceType);
  {
       // Grab the service instance
       var result = container.GetService(serviceType);
    
       // Wrap the instance, if possible
       if (result != null)
            return SomeProxyFactory.Wrap(result);

       // Otherwise return the original instance
       return result;
  }
}

...and in the client code, using the additional decorator is as easy as:


var container = new ContainerDecorator(new SimpleContainer());

// Use the container somehow and transparently use the decorator to wrap the
// result
var service = container.GetService<ISomeServiceType>();

// ...

As you can see, the implementation of LinFu.IoC is very straightforward, and there's really nothing exotic about the design. For those of you who were probably wondering why LinFu.IoC isn't using generics, here's the list of extension methods that completes the design:


  public static class ContainerExtensions
  {
      public static T GetService(this IContainer container)
          where T : class
      {
          var serviceType = typeof (T);
          return container.GetService(serviceType) as T;
      }
      public static T GetService(this INamedContainer container, string serviceName)
          where T : class
      {
          return container.GetService(serviceName, typeof (T)) as T;
      }
      public static void AddFactory(this INamedContainer container, string serviceName, IFactory factory)
      {
          IFactory adapter = new FactoryAdapter(factory);
          container.AddFactory(serviceName, typeof (T), adapter);
      }

      public static void AddFactory(this IContainer container, IFactory factory)
      {
          IFactory adapter = new FactoryAdapter(factory);
          container.AddFactory(typeof(T), adapter);
      }
      public static void AddService(this IContainer container, T instance)
      {
          container.AddFactory(typeof (T), new InstanceFactory(instance));
      }
  }

Again, there's nothing unconventional in the design. In the end, it's the simplicity that matters most, and that is the difference that LinFu.IoC offers.

The LinFu Reimplementation Plan, and Dogfooding

2008-07-29T16:47:00.000-07:00

Before I hit the ground coding, let's go over some of the features that were in LinFu v1.0 that will also be in 2.0:

Dynamic Proxies
Late Binding / Multiple Dispatch
Duck Typing
Mixins
Universal Event Handling
Closures with Lambda Arguments
Design By Contract
AOP (static and dynamic weaving)
Inversion of Control / Dependency Injection
Adaptive Object Models
A MyXaml Engine Clone

Aside from the fact that v1.0 has a fairly hefty feature list, one thing that I've noticed with the source is that despite those features, LinFu itself doesn't really use its own IoC or DbC facilities to improve the quality of its own code, and that's a wasted opportunity.

With that in mind, I've decided to implement the following features first:

Inversion of Control / Dependency Injection
Dynamic Proxies
Design by Contract
Static AOP Weaving

Building an IoC/DI container will help enforce a separation of concerns, and using Design by Contract in tandem with TDD will eliminate over 90% of the bugs in the code. The reason why I'm also implementing the static AOP weaving and dynamic proxy generator first is that there has to be a way to transparently inject those contracts into a service instance using a dynamic proxy without having to clutter the original source code. In addition, using the static AOP weaving in a debug build will allow me to dynamically inject diagnostic code without affecting the actual release build.

As for LinFu's Design by Contract v3.0, my goal is to make it injection-agnostic. That means that the library itself should be completely unaware of how it's actually being injected into a service instance. It will allow you to inject contracts using a 3rd-party dynamic proxy generator (such as Castle), and most importantly, it should make no distinction between LinFu's static AOP injection and its own proxy generator.

Probably the most striking difference that you'll see between v1 and v2 is that LinFu will no longer be split into multiple projects (aside from PostWeaver.exe, and the MSBuild task for LinFu.AOP). There might be some who might say that clumping all of LinFu into one DLL violates the principle of Separation of Concerns, but in practice, it will save you an untold amount of headaches when managing your project dependencies.

I realize that rebuilding LinFu is a very tall order, and I'm putting my heart and soul into this one to make sure that it's the best code that I'll ever write. This is going to take some time to redo, and I'll keep posting more and more updates on my blog as time progresses.

Behavior-Driven Development to the Rescue?

2008-07-28T19:50:00.000-07:00

I've been trying to wrap my head around how I can increase LinFu's test coverage rate for over a week now, and I have to admit that doing DDT testing (aka TDD in reverse, or post-hoc unit testing) is much more difficult than its TDD counterpart.

In contrast, TDD seems to apply a bottom-up approach to ensure that each component is functioning, and in LinFu's case, I'm going to need a top-down testing approach to ensure that all of LinFu's features work as advertised. My intent is to write each test as a specification for LinFu's behavior, and each one of these tests will ensure that LinFu behaves according to its specification.

It's by no means perfect, but it's the only practical solution that I can apply to the existing code base without having to rewrite it. At best, it seems like an ugly hack since I'll be effectively doing black box testing against LinFu instead of getting the 100% test coverage.

The other alternative, of course, is that I can do a complete rewrite of LinFu (presumably version 2.0) from scratch. (It's not a pretty option, but then again, it's no better than having to do post-hoc unit testing).

So here is my question for the developer community at large: Which option should I take, and why? If I do LinFu v2.0 with a 100% test coverage rate, will that up the adoption rate, or will LinFu v1.0 with specification tests added be sufficient enough to fix the test coverage problems?

LinFu, and Biting the Testing Bullet.

2008-07-22T13:11:00.000-07:00

Ok, I just have to admit it. LinFu still needs a lot more work. The test coverage is still 'awefully low', and despite the fact that I've kept my code clean and simple, it still doesn't take away from the fact that other programmers rely on automated unit tests to verify that your code works as advertised. I think Jeremy Miller said it best when he sent me this email:

I'm giving you an A+ for the outright coolness of LinFu and the Comp Sci nature of things, but I'm questioning the software engineering. To put it another way, I think you'll get far more adoption of LinFu if you have a better story to tell about the testing. If you retrofit a battery of automated tests to at least cover the dynamic proxy and maybe the AOP, I'd be very interested in using LinFu inside my own StructureMap project.

Jeremy definitely has a point there, and in some ways, it's a bitter pill for me to swallow. The bottom line is that LinFu won't get widespread adoption unless I can increase its the test coverage rate. The irony here is that since I have a low test coverage rate from the start, I'll be subjecting myself to some of the same ills that I woefully complained about in other developers.

With that in mind, I've decided to suspend all new development work on LinFu until I can resolve the test coverage issue. I will find a way to get to 100% unit test coverage, even if it means that I'll have to rewrite everything from scratch.

LinFu is officially on lockdown mode, and I've got some major cleaning up to do.

The Forced Hiatus and the Faulty Laptop.

2008-06-07T08:15:00.000-07:00

Today I'll be sending my laptop back to the manufacturer for repairs, and that means all my development work (including LinFu) will be effectively suspended until I can get this issue resolved. According to the manufacturer, the turnaround time should take about 7-10 business days (roughly two calendar weeks).

Meanwhile, the only 'hardware' that I'll have at my disposal will be Pen and Paper (tm), and I still have more than a few things lined up on the LinFu drawing board, even without a compiler. Development is going to screech to a halt in the next few weeks, and then I'll be back with some pretty hefty updates to LinFu. Stay tuned :)

Optimistic vs. Pessimistic Design: Which one do you practice?

2008-03-31T16:20:00.000-07:00

Lately, I've been noticing a trend in some of the object-relational mapping (ORM) tools in the market place, and the pattern that's emerging is interesting, to say the least.

In general, their feature sets seem to fall into one of these categories:

Pessimistic Design - The designers don't know which features their users will actually use, so they decide to implement nearly *every* possible mapping feature and then leave the end-user to decide how to use their ORM. This approach gives the broadest amount of features but sacrifices simplicity for documentation.

Optimistic Design - The designers assume that you're only going to use 20% of its functionality and implement 80% of the features that would be used in 100% of the mapping cases. They provide you with a general framework for the mapping and the change tracking, and they leave it to you (as the end user) to customize it to your needs. This approach makes the ORM easy to use, but the tradeoff is that it only implements a minimal feature set. The upside to this is that the code is so easy to use that it requires little to no documentation at all. It's practically self-documenting code.

From what I've seen so far, a lot of ORM implement pessimistic design, but very few actually implement the optimistic approach. Do the pessimistic designers assume that their end-users are incapable of implementing their own features, or is an optimistic approach too minimalistic to be useful at all?

With this in mind, it's quite tempting for me to write an ORM that uses an optimistic design approach. There might be some value in having an ORM that lets you do your job in a few minutes without having to sift through dozens of pages of tutorials. I'm a big pundit for large feature sets, but in the end, there's no substitute for pure simplicity.

LinFu.DynamicModel, MxClone, and the Art of Adaptive Object Models

2008-03-19T23:16:00.000-07:00

I've done it! :) Both the LinFu.DynamicModel and the MxClone (the MyXaml Engine Clone) libraries are ready for production use, and I can't wait to get started on writing the CP articles for both libraries.

A Tale of Two Approaches

As I mentioned in previous posts, LinFu.DynamicModel allows you to dynamically create an entire object model in memory at runtime without having to recompile your application. With LinFu.DynamicModel, you can either construct the model directly through code, or you can use the MxClone to create the model for you, using XML markup. I'll briefly go over each approach in the following sections, but before I do that, let's take a look at the interface implementation that we're going to dynamically generate:

A Canonical Approach: The Person Interface

Let's suppose that I wanted to dynamically create a dynamic type that looks like the following interface:

public interface IPerson
{
int Age { get; set; }
string Name { get; set; }
}

Using LinFu.DynamicModel in Your Code

Here's how you can dynamically create a type that implements the IPerson interface:


// TypeSpec objects are type descriptions that can be modified at runtime
TypeSpec personSpec = new TypeSpec()
{
   Name="PersonType",
 
   // Notice the strongly-typed properties
   Properties =
   {
       new Property<int>("Age"),
       new Property<string>("Name")
   },
};

// This will return true
bool isPerson = personSpec.LooksLike<IPerson>();
var person = personSpec.CreateDuck<IPerson>();

// Use the person object just like any other POCO
person.Age = 18;
person.Name = "Me";
// ...

Thanks to C#'s 3.0 new language features, you can easily create a model in memory with LinFu in relatively few lines of code. What makes this particularly interesting, however, is the fact that as the given TypeSpec changes, all of the IPerson instances that rely on that TypeSpec automatically "change" their behavior to match the newly-modified Person TypeSpec.

Using LinFu.DynamicModel with MxClone

Needless to say, there's a myriad of things you can do with this sort of technology, but it gets better--you can describe the same model through XML, using a MyXaml-style syntax:


<?xml version="1.0" encoding="utf-8"?>
<Root xmlns="LinFu.Reflection.Extensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
xmlns:def="Definition"  xmlns:set="Setters">
  <TypeSpec def:Name="PersonType" Name="PersonType">
    <Properties>
      <PropertySpec PropertyName="Name"
                    PropertyType="System.String">
        <set:Behavior>
          <PropertyBag/>
        </set:Behavior>
      </PropertySpec>     
      <PropertySpec PropertyName="Age"
                    PropertyType="System.Int32">
        <set:Behavior>
          <PropertyBag/>
        </set:Behavior>
      </PropertySpec>
     
    </Properties>
  </TypeSpec>

</Root>

As you can see, the XML syntax for MxClone is similar to MyXaml, with the exception of the set:Behavior element. MxClone allows you to assign object references to properties without having to give it a specific reference name (e.g., {SomeName}), and in this case, the set:Behavior element means that I'm assigning an object reference of type 'PropertyBag' to a property named "Behavior" on the PropertySpec type. (The PropertyBag class, in turn, is responsible for maintaining the state of each property on every given type instance--but for now, I'll save that for the upcoming LinFu article on CP)

In essence, MxClone is actually constructing the same TypeSpec in memory using XML markup. Having the model specified in XML allows you to change it at runtime without recompiling the application, and that could come in handy if you need to change your business model with minimal downtime. Anyway, back to the markup...

From XML to TypeSpec, in 15 Lines of Code

Now that we have the XML markup, the next thing you might be wondering about is the client code: exactly how do you convert that markup into a running TypeSpec? Here's how you do it:


// Load the engine into the container
string directory = AppDomain.CurrentDomain.BaseDirectory;
SimpleContainer container = new SimpleContainer();
Loader loader = new Loader(container);
loader.LoadDirectory(directory, "*.dll");

IMxEngine engine = container.GetService();

// The instance holder will 
// store the object graph once
// it's been instantiated by the engine
IInstanceHolder holder = new DefaultInstanceHolder();
string file = @"C:\YourDirectory\SimpleTypeSpecSample.xml";
engine.Execute(file, holder);

TypeSpec spec = holder.GetInstance("PersonType");
bool isPerson = spec.LooksLike();

// Use the person class normally
IPerson person = spec.CreateDuck();
person.Age = 18;
person.Name = "Me";

In the example above, I used the Simple.IOC container to instantiate the MxClone Engine. The engine, in turn, converted the XML markup into a working Person TypeSpec, and lastly, I used that same TypeSpec instance to create the IPerson instance. It's just that simple. :)

Conclusion

As you can see, there's quite a bit of development going on with LinFu.DynamicModel and LinFu.MxClone, and like everything else in the LinFu project, it will all remain under the LGPL license. I've put my heart and soul into this project, and hopefully, everyone will see that once the next set of LinFu articles comes out on CP. Stay tuned!

Using Selective Method Weaving for LinFu.AOP

2008-03-17T01:51:00.000-07:00

A while back, someone asked me if there was a way to make LinFu.AOP weave only certain types of methods and properties, and at the time, LinFu.AOP wasn't capable of doing that--that is, until now.

Here's how you do it. All you need to do is provide your own custom implementation of an interface named IMethodFilter and put that implementation in the same directory as LinFu.Aop.Weavers.Cecil.dll, and you're good to go. Here's a simple example:

[Implements(typeof(IMethodFilter), LifecycleType.OncePerRequest)]
public class MySampleCustomFilter : IMethodFilter
{
public bool ShouldWeave(MethodDefinition method)
{
// Intercept only public methods
return method.IsPublic;
}

}

All you have to do is put that in a separate DLL and make sure that the assembly is located in the same directory as LinFu.Aop.Weavers.dll, and you can customize it to your heart's content. It's just that simple. Enjoy!

A Peek at LinFu.DynamicObject

2008-03-13T01:41:00.000-07:00

Although it's been quite a while since my last post, LinFu has been coming along quite nicely with some recent additions. In the past month, I've managed to create two new things for LinFu:

A Dynamic Typing System for LinFu.DynamicObject, and
A MyXaml clone that will deserialize the DynamicModel from disk and load it into memory.

The Current State of Affairs

In LinFu's current state, you can only dynamically add properties and methods to DynamicObjects on a per-instance basis. Currently, there's no way to create a prototype for an entire set of DynamicObject instances and have all of those instances share the same conceptual prototype. For example, suppose that I wanted to create a Person type that looks something like this:

public interface IPerson
{
string Name { get; set; }
int Age { get; set; }
}

In order to have a set of dynamic objects emulate a IPerson instance, I would have to manually generate a Name and an Age property on each dynamic object that I needed to use. While such a scenario might be acceptable if I only needed to use a few DynamicObjects, the story starts to become quite different if that small few suddenly becomes a few hundred thousand. Suffice to say, there's quite a cost in having to set up a couple hundred thousand dynamic objects in memory at runtime. There must be a better way to do this, and thus, LinFu.DynamicModel was born.

Build Your Own Model, All at Runtime

LinFu.DynamicModel allows you to create an in-memory type specification (or prototype) of what you want your DynamicObjects to look like. You can add or remove methods and properties to this specification at runtime, all without having to create a single DynamicObject. Any DynamicObject that is attached to that type specification will effectively have all the properties and methods of that spec. The best part about all this is that all changes you make to a spec at runtime will be reflected in every single DynamicObject that uses that type specification.

For example, let's suppose that I wanted to create an implementation of the IPerson interface and have two DynamicObjects share the same conceptual Person type. Here's how it would look like:

DynamicObject firstPerson = new DynamicObject();
DynamicObject secondPerson = new DynamicObject();

// Both of these LooksLike() calls will return false
// since IPerson has yet to be implemented
Console.WriteLine("Object #1: IsPerson? {0}", firstPerson.LooksLike());
Console.WriteLine("Object #2: IsPerson? {0}", secondPerson.LooksLike());

// Create a person type with only the Name property implemented
TypeSpec personSpec = new TypeSpec();
personSpec.AddProperty("Name", typeof(string));

DynamicType personType = new DynamicType(personSpec);

// Make both DynamicObjects act like the person type
firstPerson += personType;
secondPerson += personType;

// Note: This still will return false since we haven't implemented the Age property
Console.WriteLine("Object #1: IsPerson? {0}", firstPerson.LooksLike());
Console.WriteLine("Object #2: IsPerson? {0}", secondPerson.LooksLike());

// Finally, implement the age property so that both types look like an IPerson
personSpec.AddProperty("Age", typeof(int));

// Note: Both DynamicObject instance calls to LooksLike() will now return true
// since the type they refer to now implements IPerson
Console.WriteLine("Object #1: IsPerson? {0}", firstPerson.LooksLike());
Console.WriteLine("Object #2: IsPerson? {0}", secondPerson.LooksLike());

// Use both instances normally as IPerson instances...
IPerson first = firstPerson.CreateDuck();
IPerson second = secondPerson.CreateDuck();

// ...

As you probably noticed from the example above, the only thing I needed to do was modify the TypeSpec instance and both DynamicObjects automatically changed their behavior to match the given TypeSpec. In theory, this will allow you to effectively generate an entire object model in memory without having to recompile the application. In fact, the only thing you would need at this point is a reliable way to deserialize the object model from disk. At first, using the .NET BCL's serialization mechanisms might be the easiest way to do this, but LinFu.DynamicModel's metamodel heavily relies on interfaces to provide each method and property implementation, and those interfaces cannot be serialized to disk by the classes in the System.Runtime.Serialization namespace.

Legally Infeasible

Now, since MyXaml is very good at instantiating object graphs, and LinFu's DynamicModel is nothing but a metamodel object graph, the next logical step would be to use MyXaml, but there's just one problem--MyXaml is licensed under the GPL, not the LGPL, which means that MyXaml can't be used in commercial applications unless you obtain a commercial license from Marc Clifton, or you publish the source code to your own commercial applications. Since I'm committed to making all of LinFu available under the LGPL, I had no choice but to write my own MyXaml engine from scratch, and hopefully, I can cover that in my next blog post. For now, all I can say about my unnamed MyXaml clone is that it's some of the best code that I've ever written, and this one is definitely worth the wait.

In the meantime, this should whet our appetite for what's to come in LinFu, and the future looks bright indeed.

Stay tuned!

LinFu.DynamicObject and Dynamic Object Models

2008-02-06T20:10:00.000-08:00

I've been playing around with LinFu.DynamicObject and I've discovered a way to implement a dynamic typing system that can be changed at runtime. That means that with LinFu.DynamicObject, you can assign it to a particular DynamicType instance and any DynamicObjects that depend on that same instance will actually change their methods and properties at runtime to match that particular DynamicType!

Adaptive Object Models, anyone? :)

Dynamic Method Dispatch is one thing that LinFu can do very well, and pretty soon, you'll be able to reconfigure an entire object model in memory without having to recompile the application.

Suffice to say, things are going to get interesting with LinFu as the series of articles progresses.

Stay tuned!

The Model, View, and (Virtual) Presenter Pattern

2008-01-31T07:43:00.000-08:00

One of the greatest weaknesses of the MVP/MVC pattern is that although the the model is completely separated from the view (and vice-versa), the view in the MVP pattern has to have a concrete dependency on its corresponding Presenter in order to function. At first, there doesn't seem to be a way to completely isolate all three components of the MVP pattern from each other, given that the view has to have a reference to a concrete presenter. The presenter, on the other hand, knows nothing about the concrete view, other than the IView interface that is implemented by the view itself; it's a one way dependency, and yet, something just doesn't 'feel' right here...

The Epiphany

...and then that's when the questions started to hit me: Does the presenter even have to be a concrete presenter at all? Is it possible to replace a concrete presenter with an interface type, and what would that interface look like? Are all presenters the same, or do they just all represent some sort of abstract concept that can't be centralized into a single common class?

My proposal for changing the MVP pattern is this: What if we convert the concept of the presenter from a concrete class to an abstract metaclass? If we change the presenter from a concrete class to an abstract implementation of a concept, we can effectively eliminate the dependency between all three parts of the MVP triad. It might sound complex, but the implementation is actually quite simple. In this variant of the MVP pattern, we can completely eliminate the view's dependency on a concrete presenter by converting the concrete presenter dependency into a collection of interfaces that the view requires in order to function.

A Quixotic Attempt

A naive approach would be to try to find a common interface to be implemented by presenters, but this poses a problem--no two presenters will ever be exactly alike. A presenter that will handle a list view won't always have the same interface as a presenter that handles a date field. In addition, there might be presenters which might hold some business or validation logic that other presenters might not necessarily share. In other words, we're dealing with a situation where each presenter interface allmust be heterogenous for each view type, and that makes it difficult to group all of the presenters into a single interface that could be used by each view type.

Dead End?

At first, it might seem like we have no choice but to make each presenter concrete and customize each one of them to fit their corresponding views--but what if we refactored each one of these concrete presenters into multiple interface dependencies for each view? If you think about it, a concrete presenter is nothing but a collection of different responsibilities assigned to a concrete interface. For example, a DatePresenter class might have a few methods that check if the date value presented in the view is valid. The same DatePresenter class also might have methods which can persist the date value to the database. The crux of the concrete presenter in the MVP pattern is that the date view relies on this same DatePresenter to control its behavior. There's a one-way separation between the view and the presenter, and there has to be a way to completely isolate the presenter from the view itself.

An Unnecessary Coupling

A view (for the most part) doesn't need a reference to a concrete presenter class as much as it needs a reference to the interfaces and responsibilities that each one of those interfaces represent. In fact, if I were to refactor a concrete presenter, extract each one of its interfaces, and have each one of those interfaces represent a responsibility that the target view requires, it almost seems like I've converted the concrete presenter into a de facto service container.

Each presenter responsibility corresponds to a service, and each service corresponds to an interface type. Since no two presenters are alike, one could even say that each presenter has a list of services that it offers to each view. So for me, the next logical question is this: If concrete presenters are nothing but de facto service containers, why not use a real service container (aka IoC container) and ditch the concrete dependency altogether?

If a concrete presenter is actually nothing but a degenerate IoC container in disguise, then I can take each one of the view types and replace their concrete presenter dependencies with a single dependency--a dependency on real IoC container by itself. What makes this interesting is that in this variant of the MVP pattern, the 'P' in the MVP pattern no longer exists as a concrete class. The view's concrete dependency on the presenter has been supplanted by interface dependencies supplied by an IoC container. Using this scheme, the view knows nothing about the actual presenter concrete class, and the presenter knows nothing about the concrete view class. As an added bonus, we can even separate the presenter from the concrete model by having the presenter rely on interfaces supplied by the model, and vice versa. The best part about all this is that (aside from the interface dependencies) all three parts of the MVP triad are completely isolated from one another. The only dependency that all three parts of the MV(P) pattern share is the IoC container itself, and since most IoC containers are easily configurable by design (namely LinFu), this dynamically gives us complete control over all the dependencies of a given application...

Note: So far, all of this is just theory, and I have to write it down somewhere before I forget it. I think this pattern can help quite a lot of people, and hopefully I can test it soon.

LinFu.AOP Released!

2008-01-29T00:30:00.001-08:00

After two long weeks of pounding away at the keyboard, I'm finally finished with the article for LinFu.AOP, and I'm proud to say that it's finally been released to the SVN repository for general use!

So if you haven't downloaded a copy of LinFu.AOP yet, feel free to update your SVN copy to the latest revision as soon as possible--trust me, you don't want to miss this one! :)

Now, if only CP can publish my article fast enough...

Writer's Block, or Write this Block?

2008-01-18T16:55:00.000-08:00

I've been incredibly busy over the past few weeks so I haven't had time to update my blog until now. I've pretty much temporarily frozen any further development with LinFu (aside from bug fixes) until I can get the Part VI article out the door and released to CodeProject. I don't know why, but lately I've caught a really bad case of writer's block. It seems like there's so many topics that I need to cover for Part VI, but I can't seem to flesh out all the details without reading through the current draft and finding glaring omissions in the documentation itself. Call me an obsessive perfectionist, but I won't release any article unless I know that it meets my standards.

I can't really quantify it, but my intuition is telling me something wrong here--and I won't rest until I can finally get this article fixed.

A Familiar Story, Told by LinFu.AOP

2008-01-05T18:03:00.000-08:00

Here's a simple story that shows what one can do with LinFu.AOP. Note the code listing below:

public class Person
{
public string Name { get; set; }
public int Age { get; set; }
public void Speak()
{
Console.WriteLine("Hello, World!");
}
}

public class Demon
{
public string Name
{
get { return "Captain Howdy"; }
set { throw new InvalidOperationException("Are you crazy??"); }
}
public int Age
{
get { return 999999; }
set { }
}
public void Possess(Person person)
{
DynamicObject dynamic = new DynamicObject(this);
dynamic.Attach(person);
}
public void Deposses(Person person)
{
MakeHeadSpin();
VomitGreenStuff();
throw new InvalidOperationException("Fat chance, buddy!");
}
public void MakeHeadSpin()
{
// ...
}
public void VomitGreenStuff()
{
// ...
}
public void Speak()
{
Console.WriteLine("This girl is mine!");
}
}
class Program
{
static void Main(string[] args)
{
// There once was a nice little girl...
Person girl = new Person() { Name = "Linda Blair", Age = 6 };

// Who spoke in a soft voice..
girl.Speak();

// Until one day, she played with some crazy oija board named 'LinFu.AOP', and
// then everything changed...
Demon demon = new Demon();
demon.Possess(girl);
IModifiableType modified = girl;
girl.IsInterceptionEnabled = true;

// Then some devoted priest came along and spoke with the girl, and she said:
girl.Speak();

// He took pity on the girl, and tried to free her from the demon.
demon.Deposses(girl);

// The demon resisted, but the priest was smart, and in the end,
// he subdued the demon.
girl.IsInterceptionEnabled = false;

// ..the end
return;
}
}

The Devil in the Details

Now, if you look at that code listing above, you'll notice that the Person class has no idea that it's being intercepted at all. In fact, poor little Linda doesn't know the trouble she's getting into. The Demon class was able to possess Person types because LinFu.AOP modified the Person class to allow itself to be dynamically intercepted at runtime, all without the knowledge of the said victim.

What makes this interesting, however, is that interception can be easily turned on or off depending on the value of the IsInterceptionEnabled property. In fact, if interception is turned off, the Person class will behave just like any other normal person without any performance penalties that are typically incurred by pass-through interception. If interception is turned on, of course, you'll be bound to have some performance overhead incurred, but the added flexibility bonus is staggering. With the slight decrease in performance, you can effectively take over the implementation of the entire class at runtime, and you can even customize it on a per-instance basis.

Think about it. :)

LinFu AOP, Reinvented

2008-01-05T17:16:00.000-08:00

After four days of coding and refactoring, I've done it! I've managed to rewrite the original version of LinFu.AOP to address all of the issues that I mentioned in previous posts, and now I only need to write the MSBuild task and the command-line weaver before I can go ahead and start working on the CP article. I know that LinFu.AOP has been vaporware as of late, but I can guarantee you that this is definitely worth the wait.

Aside from the features that I mentioned earlier in this blog, LinFu.AOP will add some interesting features to the LinFu Framework, such as:

Even simpler Simple.IOC integration

With LinFu.AOP, you no longer have to even reference Simple.IOC.dll in your application to use the container. For example, instantiating an IDbConnection type from a SimpleContainer instance will be easy as:

IDbConnection myConnection = New.Instance;

...that's it! Behind the scenes, LinFu.AOP will actually intercept the call made to the following class:

public class New
{
public static T Instance
{
get { throw new NotImplementedException(); }
}
}

Now, believe it or not, the code listing above is the actual implementation of the New class. What I'm actually doing is using LinFu.AOP to redirect the request for an IDbConnection instance to an appropriate factory method (in this case, the Simple.IOC container). What makes this even more interesting is that it employs the same type of XCOPY-style configuration that you would expect from LinFu; it means that if you wanted to inject any more dependencies into the container, all you have to do is drop the new dependencies into the directories, and the container will rebuild itself and that dependency will be available in the next New.Instance call!

LinFu.DynamicProxy 'Submersion'

One of LinFu.DynamicProxy's weaknesses is that its interceptor instances can only be bound to an unsealed type with all of its public methods marked virtual. With LinFu.AOP, that limitation no longer applies.

LinFu.AOP allows LinFu.DynamicProxy interceptors to intercept methods and properties on type instances without even using the proxy generator itself. This means that when LinFu.AOP intercepts a method call done against a target type, there is no intermediate proxy doing the interception. LinFu.AOP rewrites the IL in your method body and redirects it to your interceptor, all at runtime. You can even reuse the old method implementation as if you were still using DynamicProxy.

One could even say that the inteceptor has 'submerged' itself into the type implementation because the interceptor can still intercept any method on any given type as if it were still attached to the proxy--however, what makes it 'submerged' is the fact that you're actually using the true object instance itself!

To take this concept even further, LinFu.AOP supports two levels of method interception: Class-Based, and Instance-Based.

This means that you can either intercept a particular method across all instances of a given type, OR you can actually customize the method replacement (or interceptor) based on the current instance that you're using. Think about that for a moment...

...and while you're thinking about that, I'm going to go back and polish this thing up. :)

On Donuts and Method Interception Styles

2008-01-02T15:01:00.000-08:00

To keep the ball rolling, LinFu.AOP2 will support the following styles of method interception:

Donut Interception - This means that when a method is intercepted, its original implementation (a.k.a. its method body) will be left intact, but LinFu.AOP2 will inject additional behavior around the original method body--hence, the donut moniker. This can be useful if you want to inspect the input and the output of a given method without altering its implementation.

Donut Hole Interception - This means that when a method is intercepted, its original implementation is completely discarded and replaced with a different implementation altogether.

To make this interesting, LinFu.AOP allows both styles of interception to overlap each other, all at runtime. That means you can inject code 'around' a method body, and you can even replace that method body with something else altogether. Needless to say, this new framework offers a staggering amount of power not readily available in any .NET language today, and the possibilities with it are truly limitless.

(Meanwhile, all this talk of donuts is making me hungry, so I'm off to breakfast...)

LinFu.AOP2 Specifications and Requirements

2008-01-02T14:07:00.000-08:00

In general, LinFu.AOP2 must meet the following requirements:

Pervasive Method Interception - It must intercept both instance and static methods on all types, regardless of whether or not the target types are sealed or unsealed. This also includes non-virtual methods.

Type Initialization - It must intercept constructor calls and allow its users to perform custom initialization steps to each type that is created in memory.

No Proxy Required - It must do all of the above interception operations without using any form of DynamicProxy generator (whether it is LinFu, Castle, or whatnot).

Completely Transparent - The target library should not even be aware of any changes made to it by the AOP library. When I look at the source for the target library, there should be no trace or reference to any of the changes made by the new AOP library. In short, all changes should be completely invisible.

No Attributes Required - This means that it should not force the end-user to use .NET attributes at all to specify where any code should be inserted or injected. I might sound like a purist, but in my opinion, the very act of scattering attributes across your application is crosscutting in itself--and that's exactly what AOP is trying to avoid, and I'll do my best to avoid that as well.

Runtime Injection and Interception - LinFu.AOP2 must allow the end user developer to arbitrarily inject or insert any piece of code into an application, all at runtime, not compile time. This is a huge contrast to PostSharp, which only allows you to inject new method behavior at post-build (compile) time.

Language-Independent - It must be able to be used from nearly any .NET language, regardless of the target language's syntax.

Strong Name Signature Stripping - It *should* be able to strip the strong name signature right off of any signed assembly. Given the controversial nature of this particular topic, this feature is completely optional.

Fortunately, since LinFu.AOP1 met seven out of eight of these requirements (that is, everything but the strong name signature stripping), most of the implementation research has already been completed. The only thing left to do is to refine the implementation, and hopefully, it will be ready for an article release on CodeProject.

I'll post as much design notes as I can on this blog to keep everyone posted. Once I come up with any breakthroughs, I'll post some code on this blog for everyone to peruse.

Back to the Drawing Board

2008-01-01T15:55:00.000-08:00

Although my working prototype of LinFu.AOP has some stunning features such as pervasive
method interception and transparent code injection, at this point, it doesn't quite yet meet my quality standards for something that I would release to the general public, so I'm going to scrap it and start off from scratch.

Queue LinFu.AOP, take two...

The Admission That Every Developer Must Make...

2007-12-22T13:59:00.000-08:00

...is that no matter how great you think your code is, it ultimately sucks. At some point in time, the "great" code that you think you're writing will ultimately cause pain on somebody else.

The Gift That Keeps on Giving

Code is a lot of fun to write, but the more code you write, the more suffering you inflict upon others. I can't begin to stress enough that the mere presence of code itself is a symptom of a problem. It means that you had to write something because whatever requirements that you had to meet couldn't be done using the existing code that you have at your disposal. In other words, you're writing code to solve a preexisting deficiency, whether it was a deficiency on someone else's part, or your own.

Isn't it i.Ronic()?

This has to be the greatest irony of software development: we (as developers) write code to solve other people's problems, but the more code we write, the more problems we inflict on other developers that eventually have to maintain our code. In the end, someone out there has to maintain that 'wonderful' solution that you thought you wrote in yesteryear. In the end, someone else has to write their own version of your library because you had some deficiency in it that was too complicated to fix. That new library, in turn, will eventually fail to solve another problem, causing another developer to write another application to solve the new problem that couldn't be fixed using any other means.

The Path of Suffering

It's a vicious cycle that never ends, and at some point, this pain of maintenance that we inflict on other developers must somehow end. A naive solution to this would be to stop writing code altogether, but it still doesn't solve the problems that we as developers ultimately need to solve. We still need to write code in our daily lives to pay the bills, and people will still need us to write software so that they don't have to do all their work by hand. In other words, it's a necessary evil that perpetuates itself. We cannot avoid the fact that our jobs (by definition) require us to write more and more code--and that's exactly the problem. Code begets even more code, causing the suffering to continue.

Code Nirvana, and the Path of Enlightenment

This cycle seems complicated and nearly impossible to fix, but the solution is ridiculously simple: write less code.

In general, there are a few ways to do write less code:

-Design Patterns.
-Refactoring.
-Keeping it simple.

Design Patterns - A Panacea?

Unfortunately, there are some people out there that think that implementing a particular design pattern automatically leads to less code. That's not always the case. The more patterns you add to your application, the more suffering you inflict on those who have to maintain it and those who use it, and that still doesn't solve the problem of ending the suffering altogether.

It means that if you need to use multiple design patterns in your applications, more often than not, your code is far too complicated to write using the simplest possible means. Design patterns exist to simplify code, and if you find yourself scrolling through thousands and thousands of lines of code in multiple source files to figure out how your 'cool' pattern works, then you're defeating the original purpose of having those design patterns altogether: simplicity.

if (complexity == null) { // Cool! }

For me, it's always a pleasure to see someone else write something so simple that I don't have to waste any more than five minutes trying to figure out how to use their code. Unfortunately, such moments rarely ever occur for me, and more often than not, I find myself having to wade through pages and pages of their code or documentation (or both) to do something that's supposedly 'simple' to do using their software--and that assumes that they even write documentation at all.

Yet again, it becomes even more ironic because it seems that the same developers who write documentation for their code are actually compensating for the fact that their code is so complicated that it needs documentation in the first place. Even I have to admit that I'm guilty of this myself, given that I wrote a series of articles that describes how to use LinFu. It's certainly not as simple as I would like it to be, and in my opinion, admitting that it can be made simpler (or more importantly, admitting that it sucks) is the first step in becoming a better developer. In any case, the same principle for having more and more code is also true for having more and more documentation: More documentation is a symptom of complexity. It's not a feature--it's a liability. So if design patterns themselves don't necessarily mean simplicity, what about Refactoring? Does that solve the problem?

I Code, You Fix It (Later)

Refactoring is certainly one of the best things you can do for your application(s), and it definitely can reduce the coding "footprint" that you impose on developers who will eventually maintain your code. However, at the risk of sparking some controversy, if you're the initial developer, refactoring is actually something that you should avoid, and I'll explain why.

Hold Your Pitchforks...

Before I become labeled as a madman, let's analyze the etymology of the word "refactoring". The Greek/Latin root of the prefix "Re" roughly translates to "again", and the word "factoring" (according to dictionary.com) means:

2. the act or process of separating an equation, formula, cryptogram, etc., into its component parts.

The meaning of the word "factoring" (in this context) is effectively the process of designing your application. In other words, when you combine those two small phrases together into the word "refactoring", it means that your design was faulty enough to warrant a redesign of your code. So my only criticism with refactoring is this--refactoring isn't a preventive measure. It's a reactive measure that everyone (including myself) undertakes when they slowly realize that their code really, really sucks.

So when I say that you should "avoid" refactoring, what I'm actually saying is that you should avoid having to make your code so complicated that it needs to be refactored in the first place. Refactoring, in practice, is an absolute necessity; however, you can avoid refactoring altogether by making your code so simple that it makes refactoring seem ridiculous. For example, when was the last time you had to debug a property getter/setter like:

public int SomeProperty
{
get { return _someProperty; }
set { _someProperty = value; }
}

Dubya-Tee-Eff?

The above example might seem too simplistic--and some people would even scoff at the concept of debugging something so simple--but that's the idea. It's so simple that you don't have to worry about how it works--it just works. You can criticize it all you want for being so simple, but it probably took you less than a second in your mind to make a judgment about it, and move on to something else more useful. In contrast, it naturally takes several hours (or even days, weeks, or months) to solve something more complex. The point here is that having simplicity precludes the need to refactor and (thus) redesign your application, and that something I'll talk about next.

The Best Code Ever Written

The best code that I have ever seen in my life is certainly not my own; however, it's really easy to remember, and you can find it in between the two comment lines below:

// ---begin best code ever written--

// ---end best code ever written--

No, I haven't gone crazy. You might be saying to yourself that there is no code between those two comment lines. You're right.
The best code ever written is code that doesn't have to be written at all. Ultimately, it's being able to solve a problem without having to resort to writing code in the first place. There's literally no code to maintain, meaning that no poor sap has to cleanup my code in the long run. No suffering, no pain, and no mess. It's simply beautiful.

For those short of this lofty goal of not having to write code (including myself), however, my only advice is this: Simplicity is the ultimate design pattern. If you write it simple the first time, you won't have to worry about refactoring it because you "fudged" it with several other not-so-simple design patterns. You'll be able to rest well knowing that your code won't cause someone else to curse your name at 4am (your local time), and in the end, that is truly sweet indeed.

Holiday Hiatus.

2007-12-13T14:21:00.000-08:00

I'll be taking some time off for the holidays, so that means development for the LinFu framework is going to take a break for the holiday season, as well. When I come back after the new year, things will again go back to full speed. Happy Holidays!

My Love-Hate Relationship with Mono.Cecil

2007-12-09T15:00:00.000-08:00

I managed to fix the bug from my previous rant about Mono.Cecil, and I've even managed to implement some jaw-dropping method interception capabilities using that library. I can now intercept any method from nearly any .NET assembly, regardless of whether or not that method is static, sealed, and even non-virtual. The only problem with this library is that the more I explore its capabilities, the more I find myself becoming too dependent on Mono.Cecil. It might take me another year of research just to get LinFu.Reflection.Emit up and running, so for now, I really don't have any other viable alternatives to use (other than Mono.Cecil, of course).

It's ultimately a 'marriage of convenience' of sorts, and until I can make an alternative of my own, a figurative divorce is not an option.

One of these days, my bouts of NIH (Not Invented Here) syndrome are either going to either going to make me rich, or just plain insane, and since the first option doesn't seem so possible, I think the 'insanity' option just might get the best of me.

A feature that I would love to see in future IDEs...

2007-12-04T17:08:00.000-08:00

With all this talk of type inferencing on the horizon and with the coming of Dynamic Languages to the .NET platform, one feature that I would love to see in VS.NET is something I call it Intellisense, with "Type Prediction".

The concept is actually quite simple. Since dynamic languages themselves have the ability to dynamically modify their types at runtime, it would be nice if the compiler were smart enough to "predict" (at compile time) which methods and properties that a class might have at run time. So, for example, if I had a class called MyDynamicClass, and if at some point in the the class' lifetime, I wanted to add a method called DoSomething(), then the IDE should be able to effectively guess which parts of the code have a DoSomething() method available and give me an intellisense listing of all its signatures.

Then again, since we're only at the cusp of even beginning to use dynamic languages on the CLR, it'll be quite a while before anyone picks up on this idea. Oh well. :)

LinFu.DesignByContract2 Released!

2007-11-28T22:03:00.000-08:00

After nearly three weeks of churning away at Part V (not yet available on CodeProject at the time of this post) and making sure that everything works, I'm proud to say that LinFu.DesignByContract2 has been released to the project's subversion repository!

I practically froze all my other research projects until I could get this thing done. Now that it's finally complete, I can move over the rest of my projects from VS2005 to VS2008, and continue my work on IL instrumentation and writing my own version of Reflection.Emit.

Finally, I can take a break!

Enough with Mono.Cecil.

2007-11-11T16:10:00.000-08:00

After hitting several NullReferenceExceptions with Mono.Cecil's source code, enough is enough. I can't seem to make heads or tails of how to fix this problem, and frankly, I think it's pretty damn sloppy not to check for a simple null reference. Here's a chunk of the offending code:

It would be OK if this happened only once; the problem is that I can see several sections of code where they make the same mistake over and over again. The number one thing that I hate is when other people write sloppy code and it leaves me no choice but to wait for them to fix it because the code is too complicated to fix on my own. Mono.Cecil has zero unit tests, so there's hardly any way to actually determine which part of the entire library actually works. And frankly, it really doesn't matter to me whether or not they're still in 'beta', or 'alpha', or whatever version--it still doesn't excuse the fact that no matter what version your program should be, these people should have the common sense (as well as the decency) to do some basic error checking!

That's it. I'm tired of this shit. I'm writing my own library.

Introducing LinFu, Part II: Adding Dynamic Language Features to Statically-Typed Languages in .NET (A Preview)

2007-10-25T16:11:00.001-07:00

CodeProject is taking quite a while to publish a copy of Part II, so I've decided to publish a copy of it on this blog instead. You can download it from this link.

Its highlights include a few dynamic language features such as:

Late Binding
Duck Typing
Mixins
Dynamically Generated Methods

It's a pretty hefty article, but if you're looking to make your statically-typed code a bit easier by using some of the dynamic language features I just mentioned, then this article was written just for developers like you.

Enjoy!