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

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.

Comments

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

A couple comments on the particulars:

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.

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.