I have an event receiver using the VS2010 template for SharePoint 2010 and I have coded it the same way I have done many times. This time, though, it is not firing at all. It is attached to the list via the ListUrl attribute and I have confirmed that it is attached to the list by using PowerShell

$web = Get-SPWeb http://sp2010/Site/
$list = $web.Lists["List Name"]

I have tried tracing, I have tried writing to a custom event log, I have tried SandBox, I have tried Farm Solutions, I have tried setting the feature to not be activated when it is deployed and manually activating it, and when I debug in Visual Studio I get the warning that the breakpoints will never be hit. Any suggestons? At this point I am just going to try a new project.

Edit: I created a new project, as a SandBox solution and did not change anything except the ListTemplateId I set to 107. I tried both a custom and the default task list and the event receiver did not fire for item deleting events or any other.

  • 1
    WRT debugging, have you read msdn.microsoft.com/en-us/library/ee231550.aspx#FeatureEvents? "By default, when you run a Visual Studio SharePoint application, its features are automatically activated for you on the SharePoint server. However, this causes problems when you debug feature event receivers, because when a feature is activated by Visual Studio, it runs in a different process than the debugger. This means that some debugging functionality, such as breakpoints, will not work correctly." There is a suggested workaround involving disabling automatic feature activation. Mar 14, 2012 at 20:53
  • Yes, sadly, I did. I'm about to do an IISRESET right now. Mar 14, 2012 at 20:55

2 Answers 2


This sounds like you have an extra copy of DLL in your path somewhere. Try fully retracting the solution and deleting it from the farm. Then make sure that the DLL is no longer in the GAC nor in the bin or _app_bin folders underneath the SharePoint site. Restart IIS. Now redeploy your solution and you should see your breakpoints available again.

  • You think this is the issue even after having created a new project? Mar 14, 2012 at 20:52
  • If the new project has a different strong name, then no, this probably isn't the case.
    – Dave Wise
    Mar 14, 2012 at 21:01
  • IIS reset did not work but server reboot seems to have done the trick. I blame the gremlins. Mar 15, 2012 at 13:58
  • Interesting, that means it was a cached version of the DLL as suspected, but what would cache it in memory even beyond an IIS Reset? Possibly Visual Studio or the Timer or Admin services are all I can think of but if a physical restart solved the problem then you at least have a solution, albeit a rather heavy handed one.
    – Dave Wise
    Mar 15, 2012 at 14:53

Please make sure that the solution/ project is in "Debug" mode and not in "Release". The breakpoints will not work in "Release" mode.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.