Microsoft & .NET.NETEvents in .NET: Did You Know?

Events in .NET: Did You Know? content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

I am a factoid junky. I derive tremendous joy from exploring the nuts and bolts of languages. For example, did you know that the FrameworkSDK folder (usually at C:Program FilesMicrosoft Visual Studio .NETFrameworkSDKTool Developers Guidedocs) contains the Common Language Infrastructure (CLI) specification. If you want to know exactly what is and is not part of the CLI then the place to check is the specification documents. Sometimes you may be surprised by what you find.

One piece of information that may take some exploration is how events are emitted as Common Intermediate Language (CIL). CIL is the assembly-like code is written by the compiler. CIL exists to permit a just-in-time compiler to perform security checks on code before it is compiled to machine language and run. (There are other benefits here too, see my “Visual Basic .NET Power Coding” for a discussion of the benefits of CIL.) When an event is emitted to CIL two methods are emitted too. The methods are named add_eventname and remove_eventname. For example, an event named MyEvent will cause VB.NET to emit add_MyEvent and remove_MyEvent. These special methods are called event subscription methods. Their purpose is to support adding and removing event handlers from an event type. For instance, when you write AddHandler object.Event, AddressOf EventHandler (where object.Event is an object’s event that you want to subscribe to and EventHandler is the subscribing method) then the add method is called. You can verify the existence of the automatically emitted subscription methods by trying to manually introduce these methods (see Listing 1).

Listing 1: A class with an event member.

Public Class HasEvent
  Public Event MyEvent As EventHandler

  Public Sub add_MyEvent(ByVal Value As EventHandler)
    MyEvent = System.Delegate.Combine(MyEvent, Value)
  End Sub

  Public Sub remove_MyEvent(ByVal Value As EventHandler)
    MyEvent = System.Delegate.Remove(MyEvent, Value)
  End Sub

End Class

If you define the preceding class (or a class with similar methods) then you will get a compile error. The error will get two errors that indicate that these methods conflict with two implicitly defined methods (see Figure 1). And, if you check the assembly with the ildasm.exe utility then you can quickly verify that the add and remove subscription events are in fact defined automatically for you (see Figure 2).

Figure 1: Event subscription methods are added automatically by VB.NET.

Figure 2: The add and remove subscription methods shown with ildasm.exe, Microsoft’s CIL disassembler.

One might ask “why should I care?” Well, C# permits programmers to define their own add and remove subscription events. As a result a C# developer can extend the behavior of the add and remove subscription methods. One useful application of the add and remove handler is to surface an event on a constituent control. Here is what I mean.

Suppose you define a UserControl or custom control that has child controls. Now suppose you want to permit consumers to assign an event handler to an event on that child control. (This is referred to as surfacing constituent properties and events.) If you can implement an add and remove block then you can surface the constituent event; without the add and remove block you have to control a special method and assign the event handler programmatically at runtime rather than using the designer at design time. This has the affect of making it harder to consume the constituent event. Here is what the add and remove block for a C# event my look like.

private event EventHandler myEvent;
public event EventHandler MyEvent
    myEvent += value;
    myEvent -= value;

The event myEvent (case counts in C#) defines the storage for the event. This could be an event on a constituent control. The public event declaration, MyEvent, defines an add and remove block. In the example we are only performing the same work that the default subscription methods would perform, but we could add any code we desired.

I am not sure why subscription methods are not available to VB programmers, but in some situations-like surfacing constituent control events-the technique is especially useful.


The Common Language Specification (CLS) defines the minimum things that a language must support to be compliant. There are optional features too. One such optional feature seems to be whether the programmer can write add and remove subscription blocks for events. The worrisome aspect of compliance is that VB.NET might slowly evolve to have fewer of the cooler features that her brother C# will have.

There are some very cool new language features in C#-like operator overloading-and likely many more cool features to come. Personally and professionally I hope VB.Net is not left out of this bounty. To a degree it is up to VB.NET developers. If we make our voices heard then history won’t repeat itself, leaving VB the poor cousin once again.

About the Author

Paul Kimmel is a freelance writer for and Look for his upcoming book Visual Basic .NET Power Coding from Addison-Wesley. Paul Kimmel is available to help design and build your .NET solutions and can be contacted at

# # #

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories