Don’t wear woven sweatshirts, instead weave your assemblies

This blog posts is part of a series of blog posts about Simon Cropp’s awesome Fody project. For an overview over the blog posts please read this article.

We are living in exciting times. Compilers are getting an extensible pipeline with Roslyn and new fancy scripting projects are born every day around scriptcs. But some dynamic concepts like Aspect Oriented Programming and IL weaving have been around for many years. Tools which enable aspect oriented programming with .NET can be found under famous names like Linfu.DynamicProxy, Castle.DynamicProxy, PostSharp, AfterThought and many more. Some of those projects are free and are still actively maintained, some not and some are commercial.

The main difference between dynamic proxy and weaving approaches are that during runtime, when an object is resolved by your favourite container, a proxy is built up which has a series of interceptors. The generated proxy has the same methods and properties as the proxied class but on each call invokes the interceptors which can decide to either modify the method parameters, return values or decide to never call the target object itself. Weavers like PostSharp and AfterThough hook into the build pipeline and rewrite the output assemblies by weaving new behaviour into the existing code. The biggest advantage weaving offers is that it doesn’t suffer performance impacts during runtime, all newly woven behaviour is statically compiled into the target assembly. The disadvantage weaving has is that you cannot define behaviour on data which is only available during runtime, which can be achieved with dynamic proxy approaches. In this blog posts I will introduce a compile time weaver called Fody.

As previously mentioned Fody is a compile time weaver. It is created by Simon Cropp. Simon Cropp is a IL-freak to say the least (I would compare him to Chris Angel the Mindfreak but Simon doesn’t read your mind but manipulates your IL ;)). Let’s dive deeper into Fody. Fody alone is not really useful. Maybe that is an unfair statement because Fody actually handles the following tasks extremely well:

• Injection of the MSBuild task into the build pipeline
• Resolving the location of the assembly and pdb
• Abstracts the complexities of logging to MSBuild
• Reads the assembly and pdb into the Mono.Cecil object model
• Re-applying the strong name if necessary
• Saving the assembly and pdb

Fody Uses Mono.Cecil and an add-in based approach to modifying the IL of .net assemblies at compile time.

• No install required to build
• No attributes required
• No references required
• Supports .net 3.5, .net 4, .net 4.5, Silverlight 4, Silverlight 5, Windows Phone 7, Windows Phone 8, Metro on Windows 8, Mono, MonoTouch, MonoDroid and PCL

But the strength of Fody comes only together with a ton of community built addins which are based upon Fody’s extensible pipeline. I want to give you a short overview over Fody’s addin ecosystem at the time this blogposts is published.

• EmptyConstructor
  Adds an empty constructor to classes even if you have a non-empty one defined.
• Anotar
  Simplifies logging through a static class and some IL manipulation.
• Scalpel
  Strips all testing code from an assembly
• PropertyChanging
  Injects INotifyPropertyChanging code into properties at compile time.
• PropertyChanged
  Injects INotifyPropertyChanged code into properties at compile time
• Validar
  Injects IDataErrorInfo or INotifyDataErrorInfo code into a class at compile time.
• Costura
  Embed references as resources
• Virtuosity
  Change all members to virtual as part of your build.
• Stamp
  Stamps an assembly with git data.
• NullGuard
  Adds null argument checks to an assembly
• and many more…

So actually you only directly get in contact with Fody itself when you are writing an addin. In all other cases you just add a Fody addin to your solution (preferable with Nuget) and the addin will automatically do its magic. The nuget packages of the addins do the necessary tasks to register the addin in the FodyWeavers.xml and therefore enable the addin itself. Fody  is released under MIT License. You can download and find the nuget packages here. Be sure to check out the github repository of Fody here and my future blog posts about some of the amazing Fody addins. Don’t forget to thank Simon Cropp for this wonderful tool!