Re-attach Event Receiver to library

Question

Using SP 2010, we created a content type with an event receiver bound to the content type. The ER is an ItemDeleting ER that prevents deletes from the library. When we create a library and attach the content type, the event receiver is successfully attached to the library (we use SP Manager to confirm the event receiver is attached to the Event Receiver node in SP Manager), and it fires correctly preventing deletes - all is well.

However, during the course of things, we needed to delete the event receiver from a few libraries to perform some item deletes. We did so programmatically by finding the library and performing a delete of the ER. When done, we reattached the ER to the library directly using the SP object model, so the ER on the library is a direct association to the library and not via the CT.

Now we want to fix this so all the ER's are attached to the libs due to the CT binding, and not a direct bind on the library. We deleted the ER from the offending libraries, but now can't seem to get the ER bound to the CT to 're-attach' to the library. Using SP Manager, we see no ER in the ER node for the library, although the Content Type is still attached to the library. The users can delete items because no ER exists, even though the CT is still bound to the library (and the CT still has the ER bound to it as confirmed via SP Manager).

How can I get the ER bound to the Content Type to 're-attach' to the library? As a test, we can create a new library, use SP Manager and see no custom CT's or ER's bound to the library. Then add the CT to the library, and in SP Manager you can see the CT under CT node, and the ER under the ER's node. So it works as expected when we use the GUI to add the content type to a library, but with data in the library existing, we can't delete and re-add the CT or we'll lose data.

How can we programmatically get the CT's ER to re-attach to the library?

Answer 1

You can use powershell to add event recievers to a list.

$web = Get-SPWeb "http://yourwebsiteurl"
$list = $web.Lists["your list name"] 
$list.EventReceivers.Add([Microsoft.SharePoint.SPEventReceiverType]::ItemDeleting, "Full Assembly Name", "Full.Class.Name") 

You can also run this powershell to get the assembly/class names (you will have to find it in the output, and run it on a working spweb):

Get-SPWeb "SPWEBURLHERE" | % {$_.EventReceivers} | where {$_.Assembly -like "*"} | Select Assembly, Class

More References:

http://devinthefastlane.wordpress.com/2012/10/05/add-remove-event-receivers-to-list-content-types-in-sharepoint-with-powershell/

Answer 2

BlueBird's method works, but I would strongly recommend tying the event receiver to a solution and then deploying/retracting it that way. There are some very good reasons for this:

1. You probably don't want an orphaned event receiver sitting in the GAC. For one thing, a future administrator could look at it, say "hey, why is this thing turned off? Maybe it's related to Problem X that we're currently having?" and turn it back on and possibly break things. For another, it's just messy. SharePoint is already kind of a messy program and in my opinion it's generally a good idea to keep it as clean as you can keep it.

2. For your particular issue, which is something that you could easily find yourself running into in the future, the whole installing/uninstalling the associated SPSolution will fix this. Running Uninstall-SPSolution keeps the solution in the solution store but removes it from the GAC (and removes application pages which may have been part of the solution, etc.) but does not remove feature associations. That means that when you run Install-SPSolution after you're done, that event receiver will automatically recouple with any list you previously had it connected to.

3. It's just plain good practice. If your company gets large enough that you have to outsource development of a project, you're really, really going to want those devs to wrap things up into solution packages, and it's a lot easier to get them to do this when your stated process is to do this yourself.

This may be a little bit of closing the barn door after you've let all of the horses run out, but yeah... use .wsp files.

Answer 3

I was about to ask the same question here myself, since I am in a similar situation (needing to remove some event receivers from lists, but the event receivers are bound to content types, not the list directly, and I will want them back eventually).

What I found was that, if you delete the event receiver from the list, you can get it to re-attach via the content type if you delete it from the content type definition (at the site level), call update(true), and then re-add it to the content type definition (again, at the site level) and call update(true) again.

When you delete it from the content type and call update, you will effectively be deleting it from all lists that are using that content type, but if you add it back immediately it will only be gone for a few seconds. And that does work to add it back to the lists where you had previously removed it from the list.