﻿using System;

namespace PropertyChanged
{
    /// <summary>
    /// Include a <see cref="Type"/> for notification.
    /// The INotifyPropertyChanged interface is added to the type.
    /// </summary>
    [AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
    public class ImplementPropertyChangedAttribute : Attribute
    {
    }
}
﻿using System;

namespace PropertyChanged
{
    /// <summary>
    /// Specifies that PropertyChanged Notification will be added to a class.
    /// PropertyChanged.Fody will weave the <c>INotifyPropertyChanged</c> interface and implementation into the class.
    /// When the value of a property changes, the PropertyChanged notification will be raised automatically
    /// See https://github.com/Fody/PropertyChanged for more information.
    /// </summary>
    [AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
    public class ImplementPropertyChangedAttribute : Attribute
    {
    }
}

Improve the interface documentation for the attribute
Improve the interface documentation for the attribute

I had a discussion with a coworker. It went like:
Him: "Dude that's not going to work. You need to raise PropertyChanged when changing a property. Don't you know MVVM?"
Me: "It's compile-time weaved into the code".
Him: "What are you talking about?" (looking at me like i'd be insane)
Me: "Yeah, you know, AOP. You allways need to raise the PropertyChanged event when any property on any ViewModel changes. It's too boring and i'm too lazy, so i use this (PropertyChanged.Fody) tool which is doing it for me"
Him: "That sounds strange. I don't think this can work reliably. And it's way too complicated anyway. How would i know that it works like that and what it's doing? Do we really need something that complicated for something that simple? It's just a few lines of code per property. And you know, we can use some base class and reflection so it's refactor safe. Or we can use the new net4.5 feature [CallerMemberName]"

It went on for a while. Suffice to say that i managed to convince him of PropertyChanged.Fody's merits. However, one valid concern remains:

There's still very few developers using AOP / Fody in generall. In my company we are a few dozen .net developers. Only 3-4 know it. I'm working on improving that.

But anyway, i thought that a somewhat intelligent being confronted with legacy code would at least notice the [ImplementPropertyChanged] attribute. And thus i think it's necessary that the attribute's documentation, which can be seen in VisualStudio, should contain a bit more information, including a link to the project.
Because the property may very well be how the developer get's into contact with this awesome tool for the first time!