Search This Blog

Wednesday, 27 February 2013

Issue with Add as a new version to existing files in SharePoint 2010 Document Library


Recently I have found an unknown issue in SharePoint 2010 while upload document (from MS Office 2007) in to Document Library with the option “Add as a new version to existing files”. Below I have explained the issue in detail.

Note: Issue cannot resolve by SharePoint develpment team from Microsoft as on Feb 2013.

Issue:
ListItem Properties wiped out while upload file from MS office 2007 or MS office 2010(*.docx, *.xlsx, etc…). Review the replication procedure to understand the issue clearly.

Replication Procedure

Note: Issue can reproduce with Overwrite existing files option, when versioning not enabled.
      1.      Create a Document library
      2.      Enable versioning (Major or Minor)
      3.      Library Settings à Advanced settings àAllow management of content types à Yes
      4.      Upload a file (from MS office 2007 or MS office 2010, ie. *.docx,*.xlsx)
a.       SharePoint redirects to an application page to enter value for ListItem properties, i.e. Name, Title (Name already filled with file name)
b.      Enter value for “Title” property
      5.      Upload again the same file, which has been uploaded previously (ensure you have selected “add as a new version to existing file” check box)
a.       This time also SharePoint redirects to an application page to enter value for ListItem properties.  
b.      Expected Result: Previously entered value should be available for all ListItem properties, In our case the value for “Title” field should be available.
c.       Actual Result (Issue): Here the value for Title field is null, previously entered value is wiped out.
Repeat the step 4 and 5 with file from MS office older than 2007 or any other file type (like *.txt, *.pdf), where you won’t get the issue reported in step 5c. These file types (*.doc, *.xls, *.txt, *.pdf) are working correctly, we get our expected result (mention in step 5b). So this issue exists only with MS office 2007 and MS office 2010 files.

Refer my post in social. TechNet forum through below link

Workaround through SharePoint Development
The only way to handle the issue is “Event Receiver”, for that you should enable versioning in that document library.

Tuesday, 5 February 2013

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.