What Fody means to NotifyPropertyWeaver

Some history

In mid 2011 I ran with an idea from Justing Angel on how to implement INotifyPropertyChanged through the use of Cecil and IL Weaving. This project eventually evolved into NotifyPropertyWeaver. With the main delivery mechanism being a Visual Studio Addin. It has been a fairly sucessful project and I think it is an elegant solution to the problem.

Applying the pattern to other problems

Since then I have re-applied the pattern to solve a variety of other problems. For example

• Making members virtual by default
• INotifyPropertyChanging
• Injecting module initialisers
• Converting fields to properties

Some of these made it to full projects and some did not.

So what was holding me back

There are a few reasons I didn't just keep on pumping out stand alone projects to solve these problems.

Effort

Each project would require an associated Visual Studio Addin. If you have ever had to work with the Visual Studio API you will know it is painful in the extreme. For some of these targeted IL Weaving solutions the Visual Studio code would equate to 90% of the code base. It is also very difficult to share common code accross different IL Weaving projects.

Testability

Due to the COM based nature of the Visual Studio API it is very difficult to perform tests against code that uses it.

Practicality

Like most people I am uncomfortable installing too many Visual Studio Addins. Visual Studio is fragile enough without installing heaps of other addins.

Difficulty updating

Visual Studio and MSBuild lock assemblies containing MSBuild tasks. This means updates to NotifyPropertyWeaver required a restart of Visual Studio before that update would be applied to your build.

Performance

With the approach used by NotifyPropertyWeaver every IL Weaving project would need to do a full read and write of the assembly being manipulated. This results on significant disk, CPU and memory load during build time. The end result is a slower build.

Enter Fody

https://github.com/Fody/Fody

Fody solved the above problems with the following

• By only having one Visual Studio addin.
• Consuming addins via nuget.
• Managing a single read and write of the assembly.
• Orchestrating the addins at build time through a new AppDomain so they are not locked. This means they can be updated with no Visual Studio restart.

So each IL Weaving project now only needs a single nuget package and is ignorant of the reading and writing of the assembly.

What this means for NotifyPropertyWeaver

PropertyChanged Fody Addin

First off if you want to make use of the above benefits of Fody you can use the PropertyChanged Fody addin. It is roughly feature equavelent ot NotifyPropertyWeaver.

NotifyPropertyWeaver will remain

So the specifics for NotifyPropertyWeaver

• It will not be decommissioned.
• Bugs will be actively fixed, especially since most bugs are likely to exist in the PropertyChanged Fody Addin
• New features are unlikely to appear in NotifyPropertyWeaver. Effort on new features will be focused on the PropertyChanged Fody Addin or other Fody Addins. For example rather than add INotifyPropertyChanging support to NotifyPropertyWeaver I created PropertyChanging Fody addin.

NotifyPropertyWeaver and Fody together

If you are happy to ignore the build performance issues listed above then NotifyPropertyWeaver and Fody can work together in the same solution. This is the same scenerio as using Fody and any combination of the following IL Weavers.

• PostSharp
• Code Contracts
• Fire Weaver
• Confuser
• MindOfMagic

While Fody's interaction with these tools is not in the core unit tests any problems will be considered a bug.

Summary

So I hope this answers most of the questions I have been asked recently regarding Fody and NotifyPropertyWeaver.