Is there a special association between the EventArgs class and the event keyword?

Question

In all the .NET book I've read the guide line for implementing events explains that you need to subclass EventArgs and use EventHandler. I looked up more info on http://msdn.microsoft.com/en-us/library/ms229011.aspx, and it says "Do use System.EventHandler instead of manually creating new delegates to be used as event handlers." I understand that there are important reasons to use EventArgs, but my question is not "Should I do it this way?", but "Can I do it this way?".

Is there any reason that I can't use a generic delegate instead of an EventHandler with my events? For example, if I want a strongly-typed sender (anyone else get annoyed by that object sender?) .

To explain what I mean better, is there any reason the following won't work?

public class IoC
{
    public AbstractFactory GetAbstractFactory()
    {
        var factory = new AbstractFactory();
        factory.CreateObject += ()=>new object();
        return factory;
    }
}
public class AbstractFactory
{
    public event Func<object> CreateObject;

    private object OnObjectCreated()
    {
        if(CreateObject == null)
        {
            throw new Exception("Not injected.");
        }
        return CreateObject();
    }


    private object _injectedObject;
    public object InjectedObject
    {
        get
        {
            if(_injectedObject == null)
            {
                _injectedObject = OnObjectCreated();
            }
            return _injectedObject;
        }
    }
}

Answer 1

It's just convention, and no requirement of the language. You can use any delegate type as an event.

The standard EventHandler<T> signature has a few advantages though:

1. You can extend the EventArgs parameter. This wouldn't work if you had one parameter for each thing you want to pass into the eventhandler.
2. An EventHandler which accepts the EventArgs base-class can subscribe to any event following the convention
3. You can add Extension methods to EventHandler<T> which appear on all events.
4. Return type is void. Other return types don't make much sense as eventhandlers.
5. You're following the convention. Following the convention is usually a good idea, unless you have compelling arguments not to.

Answer 2

All of the documentation from Microsoft is about the design of the base class libraries and/or general framework design guidelines. You can use whatever pattern you want.

That said, if people will be consuming your code it will be more familiar to them if you follow the patterns that Microsoft uses.