When you use Visual Studio 2010 to create an Event Receiver for a list, it prompts you to select the type of Event Receiver you want to create (List Item Events) and which item should be the event source. Selecting any of the options in this second drop-down might make you think twice – “I don’t want this firing for all Custom Lists in my site!”
There are two routes you can take to get your event receiver to only fire for a specific list.
1. Modify the Elements.xml file
This is by far the easiest way to do things. Open up your Event Receiver Elements.xml file and find the Receivers tag. It should read something like <Receivers ListTemplateId="100">, where the ListTemplateId depends on the type of list you selected from the Wizard (100 is the ListTemplateId for Custom Lists).
Delete the ListTemplateId attribute and replace it with a ListUrl attribute: <Receivers ListUrl="Lists/MyListName">
The Feature that contains this Event Receiver must be scoped to a Web level. However, if the list you’re targeting is in a subsite (i.e. not in a top-level site) you might find that using VS2010 to deploy your solution won’t work. This is normally because you have set your Features to activate automatically on deployment, and during deployment you’ll get an error during the activating features step: "Error occurred in deployment step 'Activate Features': <nativehr>0x80070002</nativehr><nativestack></nativestack>"
This is easy to fix – you just need to alter the Site URL for your project. To do this, single-click on your project name in the Solution Explorer (not the main Solution node, but the one under it). In the Properties pane, find the Site URL property, which you’ll see is set to your top-level site URL. Simply add the remainder of the URL to point to your subsite (i.e. original Site URL property was http://sharepoint, change to http://sharepoint/mySubSite).
Once you’ve done this, you should be able to successfully deploy your solution through VS.
To avoid the error altogether, you can set the ‘Activate on Default’ property of the Feature that contains your Event Receiver to False. To do this, expand the Features node in the Solution Explorer pane and find the Feature that contains your Event Receiver. Double-click the .feature file and view the Properties pane. The top option, ‘Activate On Default’, should be changed to ‘False’. You’ll then have to navigate to your sub-site and activate the Feature manually.
2. Modify your Event Receiver code
The alternative, which I don’t like, is to add code to your Event Receiver to check that it is running on the correct list. You’ll need to access the List property and check that it’s the one you want it to run on. Depending on the type of Event you’re listening for, this will be slightly different, but for ItemAdded and ItemUpdated (and other events that fire after the change has been committed), you can do this by accessing the SPItemEventProperties.ListItem.ParentList field. In any of the overridden events, you’ll need to check that properties.ListItem.ParentList.ID (or properties.ListItem.ParentList.Title (although that’s risky – what if you have two separate sub-webs, each with their own List called MyCustomList?) equals the List you’re looking for.
The reason I don’t like this method is that the Event Receiver is attached to all Lists of the type you selected regardless of whether it’s the one you want, it’s just the code doesn’t run when the Events you’ve overridden occur. That can be extremely confusing for anyone looking at Event Receivers attached to lists.
There are only 10 types of people in the world 