The event handler in WSS 3.0

[Computer_Freak]

The event handler is one of the most useful feature for customizing the features of Windows Sharepoint Services. In other words, through these mechanisms, you can run the code contained in a. NET assembly to the outbreak of the majority of transactions on an object, Sharepoint, and the work ranging from simple insertions, deletions and changes to arrive at the check-in / check-out documents, and upload a file deletion / creation sites or subsites. The event handlers were already present in the earlier version of the product (2.0), but they were only applicable to the document library, now in version 3.0 of WSS, the support for these mechanisms was added to all types of lists in the configuration of Sharepoint default, individual files, sites and features (one of the novelties of the new version of the product). In addition, the concepts on which were based the first event handler, have been significantly renovated, with the introduction of new features. Let's see in detail:

1. You can handle events for individual files, lists, sites and features.
2. Support all types of lists, is the default, that custom ones created by us.
3. You can register multiple events for a single object.
4. We can take advantage of synchronous events (before-events) and asynchronous events (after-events).
5. can stop the execution of a synchronous event and print to video of the custom error messages.
6. can be recovered, as well as changes to the content of particular items, even to their scheme (for example, additions or changes to fields in a list).

Sharepoint itself, makes a great use of its event handlers. Just look, for example, the mechanism by which a workflow is started: the creation, we can choose whether to start the flow when inserting a new item in a list (Event ItemAdded) or modification of an item already exists at ' inside the list (event ItemUpdated).

[Computer_Freak]

First event handler

As a first example, we fall into banality and create the classic Hello World. Then we create a new project in Visual Studio. NET 2005, select the "Class Library" and our favorite language (C # is fine and proceed with creation.
Once the project is created, we must first do two basic things:

• inclusion of the reference library Microsoft.Sharepoint.dll
• Creating a key and sign the assembly with a strong name, so it can be incorporated into the GAC of the SharePoint server.

The first step we need to enable intellisense within our Visual Studio project, for all the classes that are part of the Sharepoint Object Model. The second, however, is essential for the proper recording of the event handler, since the assembly for it must be placed in the GAC (Global Assembly Cache) for the server to be registered and to function properly. To do this, simply follow these instructions:

• Right click on the project and select "Properties",
• go to the tab "Signing"
• choose the option to sign the assembly,
• create a new key by selecting "New" in its combo
• write the name of your keys (can be any),
• complete the procedure by clicking OK.
• Or, follow the procedure set out by hand in this documentation page .

Without this, we add a new class to our solution and ereditiamola SPItemEventReceiver from class, base class for event handlers to be applied to Sharepoint lists. This class is then instantiated by Sharepoint every time a transaction takes place on its list. If, within our class, we wrote the code to overload any method that handles some event in the list, this will be executed by the system, otherwise the operations launched on the list will continue normally. In the example, we write the phrase "Hello world event handler!" in the Title field of each element that is added into the list where we recorded our handler.

  namespace Peppe.Sharepoint.Handlers

  {

  public class HelloEventHandler: SPItemEventReceiver

  {

  public override void ItemAdding (SPItemEventProperties properties)

  {

  properties.AfterProperties ["Title"] = "Hello world event handler!"

  }

  }

  }

The use of the property AfterProperties SPItemEventProperties class, we have an instance in each event handled by our handler, we can retrieve or set values for all fields of the item being added, as this still is not present in the content database and then, the equivalent ListItem properties, which is instead used in almost all the after-event, is still nothing. In summary, the AfterProperties are valued in all the events of each type of list, while the ListItem properties, which represents the element on which the event was triggered, is available (with updated values) only in the after-event, except ItemDeleted the event (for obvious reasons).

[Computer_Freak]

Register an event handler

Ok. We just created our first event handler. Now we must register it and attach a list of a SharePoint site. To register the handler, we can use the use of a feature (one of the new mechanisms of Sharepoint Services 3.0, for this implementation refer to the reading of this tutorial ) and to attach it to an object we must write code. NET make a windows form, or simply a console application that transaction through the SharePoint object model. We see, therefore, the implementation of a console application that registers the event handler for example we saw previously:

  namespace AddHandler

  {

  class Program

  {

  static void Main (string [] args)

  {

  SiteURL String = ConfigurationManager.AppSettings ["SiteURL"];

  string listname = ConfigurationManager.AppSettings ["listname"];



  using (SPSite site = new SPSite (SiteURL))

  {

  using (SPWeb web = site.OpenWeb ())

  {

  SPList list = web.Lists [listname];

  list.EventReceivers.Add (SPEventReceiverType.ItemAdding,

  "Peppe.Sharepoint.Handlers, Version = 1.0.0.0, 

  Culture = neutral, 

  PublicKeyToken = 78fde53655a71179 "

  "Peppe.Sharepoint.Handlers.HelloEventHandler");

  list.Update ();



  Console.WriteLine ("Handlers inserted successfully!");

  }

  }



  Console.WriteLine ("Press any key to exit ...");

  Console.Read ();

  }

  }

  }

Note: I, for mere convenience, I usually add a second project to my solution and create a console application as soon as this view, that you register handlers. E 'but also a free tool to avoid this job: Event Handler Explorer (directly from the blog of Patrick Tisseghem MVP - U2U). Moreover, the choice of registering the handler in code, was included as a new feature in version 3.0 of Sharepoint (which we will see more news in the next chapter). EventSinkAssembly remain functional properties, and EventSinkClass EventSinkData via web interface.

Before we launch this console application from the server where Sharepoint is installed, we put the assembly containing our handler in the Global Assembly Cache (GAC) of the server itself. To do this, we can go to Control Panel> Administration Tools> Microsoft. NET 2.0 Configuration> Manage the assembly cache> Add an assembly to the assembly cache, and select our dll, or you can create a. Bat file containing these instructions:

  gacutil / U Peppe.Sharepoint.Handlers

  gacutil / i Peppe.Sharepoint.Handlers.dll

  iisreset

That do nothing to remove the assembly from the GAC (if already installed), install it again (in case there was a new version) and finally to reset the IIS web server.

Note: The reset is necessary to warn of Sharepoint presence of a new version of our assemblies in the GAC.

Now the handler is connected to our list. By creating a new item, you can see its proper functioning.