title: If events are implemented as delegates in .NET, what is the point of the .event IL section?
body: <p>I've seen some very good questions on Stack Overflow concerning delegates, events, and the .NET implementation of these two features.  One question in particular, "<a href="https://stackoverflow.com/questions/213638/how-do-c-events-work-behind-the-scenes#213651">How do C# Events work behind the scenes?</a>", produced a great answer that explains some subtle points very well.  </p>
  
  <p>The answer to the above question makes this point:</p>
  
  <blockquote>
    <p>When you declare a field-like event
    ... the compiler generates the methods
    and a private field (of the same type
    as the delegate). Within the class,
    when you refer to ElementAddedEvent
    you're referring to the field. Outside
    the class, you're referring to the
    field</p>
  </blockquote>
  
  <p>An MSDN article linked from the same question ("<a href="http://msdn.microsoft.com/en-us/library/aa664455.aspx" rel="nofollow noreferrer">Field-like events</a>") adds:</p>
  
  <blockquote>
    <p>The notion of raising an event is
    precisely equivalent to invoking the
    delegate represented by the event —
    thus, there are no special language
    constructs for raising events.</p>
  </blockquote>
  
  <p>Wanting to examine further, I built a test project in order to view the IL that an event and a delegate are compiled to:</p>
  
  <pre><code>public class TestClass
  {
      public EventHandler handler;
      public event EventHandler FooEvent;
  
      public TestClass()
      { }
  }
  </code></pre>
  
  <p>I expected the delegate field <code>handler</code> and the event <code>FooEvent</code> to compile to roughly the same IL code, with some additional methods to wrap access to the compiler-generated <code>FooEvent</code> field.  But the IL generated wasn't quite what I expected:  </p>
  
  <pre><code>.class public auto ansi beforefieldinit TestClass
      extends [mscorlib]System.Object
  {
      .event [mscorlib]System.EventHandler FooEvent
      {
          .addon instance void TestClass::add_FooEvent(class [mscorlib]System.EventHandler)
          .removeon instance void TestClass::remove_FooEvent(class [mscorlib]System.EventHandler)
      }
  
      .method public hidebysig specialname rtspecialname instance void .ctor() cil managed
      {
          // Constructor IL hidden
      }
  
      .field private class [mscorlib]System.EventHandler FooEvent
      .field public class [mscorlib]System.EventHandler handler
  }
  </code></pre>
  
  <p>Since events are nothing more than delegates with compiler-generated <code>add</code> and <code>remove</code> methods, I didn't expect to see events treated as anything more than that in IL.  But the add and remove methods are defined in a section that begins <code>.event</code>, not <code>.method</code> as normal methods are.  </p>
  
  <p>My ultimate questions are:  if events are implemented simply as delegates with accessor methods, what is the point of having a <code>.event</code> IL section?  Couldn't they be implemented in IL without this by using <code>.method</code> sections?  Is <code>.event</code> equivalent to <code>.method</code>?  </p>