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.

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.

Posted by: Simon Cropp
Last revised: 08 Feb, 2013 11:08 PM History

Comments

26 Jan, 2012 06:25 PM @ version 1

Cool stuff. Definitely looking forward to it. Keep up the good work !

Dan M
Dan M
26 Jan, 2012 08:32 PM @ version 1

Great job. I definitely see the value in having a platform to host IL weaving add-ins.

A couple comments on the particulars:

  1. I strongly recommend putting a Sample Usage link on each add-in home page (not just on the Fody page). It took me a while to find it.
  2. I'm thinking that, if possible, items should be added/removed from FodyWeavers.xml as Nuget add-in packages are added/removed from the project. This was a major stumbling block for me until I found the "Sample Usage" page. One of the key virtues of Nuget is that it sets up everything for you.
Simon Cropp
Simon Cropp
31 Jan, 2012 11:40 AM @ version 1

@Dan

  1. good point. will do so
  2. Happy to take a patch for this one :)

No new comments are allowed on this post.