我刚刚在一个项目上运行了 VS2012 代码分析工具，发现它抱怨这个片段：
public delegate void PerMbHandler(long totalMb);
public event PerMbHandler NotifyMegabyteIncrement;
CA1009 将“MyWebClient.PerMbHandler”的第二个参数声明为 EventArgs，或扩展 EventArgs 的类型的实例，名为“e”。
事件处理程序方法采用两个参数。第一个是 System.Object 类型，名为“发送者”。这是引发事件的对象。第二个参数的类型为 System.EventArgs，名为“e”。这是与事件关联的数据。例如，如果每次打开文件时都会引发事件，则事件数据通常包含文件的名称。
MSDN 只说明了约定是什么，而不是它存在的原因。
使用long参数而不是EventArgs的子类会出现什么问题？这是约定和程序员期望的问题，还是必须遵循该模式的一些微妙的技术原因？我说微妙，因为代码似乎工作正常。
使用长参数而不是 EventArgs 的子类会出现什么问题？
Event Args
本身并没有错，但它不可扩展。为了争论，也许在 6 个月内你需要传递两个 long，或者添加一个字符串，或者添加一个完整的信息列表。在EventArgs签名中，您可以传递任何派生类型而不会破坏现有消费者；使用特定的值类型，您将受到很大限制。
EventArgs 还允许您与引发事件的类进行通信，例如CancelEventArgs.
发件人
老实说，我很少将发件人用于任何事情。它也可能有点模棱两可。例如，由输入到文本框触发的控件上的自定义事件......谁是发件人？文本框（可能更有用），还是声明自定义事件的控件？
尽管如此，它仍然是一个熟悉的约定，并且具有良好记录的界面，它可能很有用。
什么都不会出错，事件和事件处理程序签名经过严格的类型检查。消息所做的只是警告你减速带，这会给另一个使用你的事件的程序员，对为什么事件有如此不寻常的签名感到困惑。减速带会产生错误，例如程序员坚持需要获取发送者所产生的错误。
请记住 FxCop（又名“代码分析”）试图做什么。它不检查错误，这是编译器的工作。它可以让您知道您可能没有想到的事情。正因为如此，它有时会有点烦人，尤其是当它谈论 CAS 或不恰当地标记臭名昭著的 CA2000 时。但这肯定是一个很好的警告，你没有想到。