SharePoint 2010 Event Receiver fires twice

Most of the SharePoint developer has faced this issue, “Custom event receiver fires twice for Item Updating and Item Updated event in Document Libraries”. Actually it’s not an issue; this is default behavior of SharePoint 2010 Document Libraries. This happens only at the time of uploading file in to library. I have explained the scenario below

Assume we have one Document Library with one mandatory field

Sl. No.	Description	Event Fires twice
1	While uploading a fresh document	Yes
2	While uploading existing document with either Overwrite existing file option or Add as a new version to existing file option	Yes
3	Check Out and Check In file	No
4	Edit document properties	No

So, the custom event fires twice only at the time of uploading file into library. The first time the ItemUpdating and ItemUpdated events fire it is in response to the document properties changing. The second time they fire it is in response to the document being checked in. It appears as though they are firing twice in this situation because SharePoint is updating the properties on the document and then checking it in on the same request. If you were to check the document out and edit the properties on the document, you would see the ItemUpdating and ItemUpdated events fire once. Later on, when you checked the document in, you would see those events fire again. So the double-event firing isn’t a bug, it’s just a result of the automatic check-in that occurs when you first add a document to a document library.

We can prevent this by handling code in our custom event receiver, Refer the below code snap it helps to prevent the event fires twice

if (properties.AfterProperties["vti_sourcecontrolcheckedoutby"] == null

         && properties.BeforeProperties["vti_sourcecontrolcheckedoutby"] != null)

            {

                //Code to run if event trigged by a check-in

            }

            else

            {

                //Code to run if event trigged by something else

            }

This code is using the BeforeProperties and AfterProperties on the properties parameter to see what the value of the vti_sourcecontrolcheckedoutby property on the item was before the update occurred, and what it will be after the update has completed. The vti_sourcecontrolcheckedoutby property identifies who the item is currently checked-out to. As such, if the item is being checked-in, the BeforeProperties will contain a value for the property and the AfterProperties will not. It’s a pretty simple fix, but we can definitely make it a bit more reusable for everyone on a development team and reduce the hassle of having to remember the specifics about how to run the check in their ItemUpdating and ItemUpdated event handlers.