What
Say you’ve got a SharePoint site up and running and you need to provide a hook for some custom programming logic that only occurs when certain events are triggered from SharePoint. Some examples of the most basic events would be when a user on the site adds, updates, or deletes an SPListItem (either through the OOB GUI or some custom implementation). Thinking about events in SharePoint is akin to thinking about events in C# (Click, Hover, ItemDataBound, etc…) for example. A user performs an action, and some block of code executes when that something is done (or possibly before that something is done).

Why
As was alluded to above, often times there are needs to run a block of code after (or during) an event in SharePoint. Such examples could be cleanup jobs, or potentially database-level data synchronization needs, it all boils down to the project needs.  Bottom line is most projects are predominately event-driven, so event receivers are a core part of your toolkit when integrating SharePoint into a project solution.

How
I’ll start with a birds-eye view before diving into some detailed code examples. If you want SharePoint to leverage Event Receivers, one way to do so is by authoring your own custom assembly that you strong-name and GAC. Afterwards, all that is necessary is to subscribe (a.k.a.  register if you prefer) SharePoint to the specific events within the GAC’d assembly (more on that in a moment).

Before we get into the examples of how to subscribe/unsubscribe SharePoint to particular event receivers in your GAC’d assembly, I’ll first touch on the basic structure of how to author your Event Receiver assembly.

public class CustomEventReceiver : SPItemEventReceiver
{
	/// <summary>
	/// Default constructor
	/// </summary>
	public CustomEventReceiver()
	{
	}

	/// <summary>
	/// Event raised by SharePoint after item has finished adding.
	/// </summary>
	public override void ItemAdded(SPItemEventProperties properties)
	{
		try
		{
			base.ItemAdded(properties);

			//...
		}
		catch (Exception e)
		{
			properties.ErrorMessage = "An error occurred during your request. (IA)";
			properties.Cancel = true;
		}
	}

	/// <summary>
	/// Event raised by SharePoint after item has finished updating.
	/// </summary>
	public override void ItemUpdated(SPItemEventProperties properties)
	{
		try
		{
			base.ItemUpdated(properties);

			//...
		}
		catch (Exception e)
		{
			properties.ErrorMessage = "An error occurred during your request. (IU)";
			properties.Cancel = true;
		}
	}

	/// <summary>
	/// Event raised by SharePoint after item has finished deleting.
	/// </summary>
	public override void ItemDeleted(SPItemEventProperties properties)
	{
		try
		{
			base.ItemDeleted(properties);

			//...
		}
		catch (Exception e)
		{
			properties.ErrorMessage = "An error occurred during your request. (ID)";
			properties.Cancel = true;
		}
	}
}

The above code shows that we create a custom class inheriting from the SPItemEventReceiver class (Microsoft.SharePoint namespace FYI), declare the default constructor, and declare 3 basic event receiver methods as defined in our parent class.  All accessible data pertaining to a particular event lives within the inbound properties to the method.  You’ll find as you explore the various lifecycles of events (ItemAdding versus ItemAdded) as well as matching stages across events (ItemAdded versus ItemDeleted), the inbound data that is made available to you is very inconsistent, so be aware that you’ll likely run into a lot of unexpected null’s through trial and error (pretty painful at times but unavoidable in this part of the SharePoint world).

Now that you’ve seen the basics on how to set up Event Receiver layers, the only major pieces of business left to deal with are the register/unregister blocks.  I personally find it simplest to have a utility command line tool that you make use of for leveraging your code.

public class CommandLine
{
	/// <summary>
	/// The main driver method for the console application
	/// </summary>
	public static void Main(string[] args)
	{
		try
		{
			//Establishing which eventReceiverTypes we want to support
			supportedEventReceiverTypes.Add(SPEventReceiverType.ItemAdded);
			supportedEventReceiverTypes.Add(SPEventReceiverType.ItemDeleted);
			supportedEventReceiverTypes.Add(SPEventReceiverType.ItemUpdated);

			//Registering all of our SPList's to all of our supported event receiver types
			foreach (string e in Enum.GetNames(typeof(SPListName)))
				RegisterEventReceivers(web, assembly, className, supportedEventReceiverTypes, e);

			//Unregistering all of our SPList's from all of our supported event receiver types
			foreach (string e in Enum.GetNames(typeof(SPListName)))
				UnregisterEventReceivers(web, assembly, supportedEventReceiverTypes, e);
		}
		catch (Exception e)
		{
			Console.WriteLine("Error: {0}", e.ToString());
		}
	}

	/// <summary>
	/// This method will register all supported eventReceiverTypes for a specified SharePoint list
	/// </summary>
	private static bool RegisterEventReceivers(SPWeb web, string assembly, string className, List<SPEventReceiverType> eventReceiverTypes, string listName)
	{
		try
		{
			foreach (SPEventReceiverType eventReceiverType in eventReceiverTypes)
			{
				SPEventReceiverDefinition def = web.Lists[listName].EventReceivers.Add();
				def.Name = eventReceiverType.ToString();
				def.Synchronization = SPEventReceiverSynchronization.Synchronous;
				def.Type = eventReceiverType;
				def.Assembly = assembly;
				def.Class = className;
				def.Update();
			}

			web.Lists[listName].Update();
			return true;
		}
		catch (Exception e)
		{
			Console.WriteLine("Error: {0}", e.ToString());
			return false;
		}
	}

	/// <summary>
	/// This method will unregister all supported eventReceiverTypes for a specified SharePoint list
	/// </summary>
	private static bool UnregisterEventReceivers(SPWeb web, string assembly, List<SPEventReceiverType> eventReceiverTypes, string listName)
	{
		try
		{
			List<SPEventReceiverDefinition> definitionsToDelete = new List<SPEventReceiverDefinition>();

			foreach (SPEventReceiverDefinition receiverDef in web.Lists[listName].EventReceivers)
				if (receiverDef.Assembly == assembly && eventReceiverTypes.Contains(receiverDef.Type))
					definitionsToDelete.Add(receiverDef);

			for (int count = 0; count < definitionsToDelete.Count; count++)
				definitionsToDelete[count].Delete();

			return true;
		}
		catch (Exception e)
		{
			Console.WriteLine("Error: {0}", e.ToString());
			return false;
		}
	}

	private static List<SPEventReceiverType> supportedEventReceiverTypes = new List<SPEventReceiverType>();
	private static string assembly = ConfigurationManager.AppSettings["Assembly"];
	private static string className = ConfigurationManager.AppSettings["ClassName"];
	private enum SPListName
    {
        ListName1,
		ListName2,
		ListName3
    }
}

As can be seen above, there is a main driver method that declares which events we care about, then it simply subscribes each SPList to all of the events, followed by unsubscribing each SPList from all of the events (for the sake of providing both examples of course).

One thing to note here is that I intentionally declare the SPEventReceiverDefinitions in this fashion (there are other shorter ways) so that you have the ability to specify “Synchronous” (the default behavior is asynchronous).  Now because these are synchronous, you’ll notice back in our assembly logic up top, we set the properties.ErrorMessage and properties.Cancel properties accordingly.  These help control the synchronous flow of the web request by the triggering user.  So if something fails in the event receiver layer, the code is smart enough to signal back to the calling web tier that a problem occurred.  If the event receivers had been set up asynchronously, then the ErrorMessage/Cancel properties would be of lesser use.  Nevertheless, I hope this has been an informative overview / quick start for leveraging Event Receivers with SharePoint 2010, good luck!

P.S. – Since your event receiver assembly is in the GAC, anytime you make a change to the logic and re-GAC it, don’t forget to perform an IIS reset or SharePoint will hold onto the old version of the GAC’d assembly.