Problems with "AfterProperties" in list event receivers

This is to summarize the inconsistent behaviors I encountered when working with "AfterProperties" in "ItemUpdating" event handler on a custom SharePoint list in SP 2010.

1) AfterProperties will be NULL when ItemUpdating event is called because of a code-update to list:

This is something that is not documented, and lead me into a lot of trouble:

Consider this scenario:

My SharePoint list had a column named "Email".

I wrote an "item-updating" event handler that will update a few other child lists with updated Email, when it was altered in the parent list..(to which the event handler was attached)

Here is the code:

string oldEmail = (properties.ListItem["Email"] == null) ? "" : properties.ListItem["Email"].ToString();

string newEmail = (properties.AfterProperties["Email"] == null) ? "" : properties.AfterProperties["Email"].ToString();

if(oldEmail != newEmail )

{

     //Update the other child lists with "newEmail"

}

I tested this code by editing the list item and updating the Email and the change was correctly propagated to  the other lists. 

After a few days we noticed that a lot of items in those child lists, had empty email values.

Reason:

When the item in parent list is edited directly using the SharePoint interface, then both properties.ListItem["Email"] and properties.AfterProperties["Email"] has the expected values.

But, when the list is being updated by code, and the code does not update the "Email" (for example, the code just updates "First Name" in the list)  then properties.AfterProperties["Email"] will be NULL in the event receiver code. AfterProperties will have the correct value, only when Email is also updated through code.

This was not the case when editing was done through SharePoint UI.( i.e If I edit that item and change only the "First Name", then AfterProperties["Email"] had the correct value..)

Because of this my event receiver had reset Email in all the child lists with empty values.

Resolution:

Unfortunately, the only resolution available was to check whether "AfterProperties" is NULL and in that case assume that the list item is updated through code somewhere else, and do nothing..

2) Dealing with "Lookup" columns:

If you are handling a "Lookup" column using "AfterProperties", then be careful. It looks like a bug where "AfterProperties" contains only the "ID" part of look-up and not the whole look-up value.

Consider this example, where I am checking whether a look up column value has been altered:

SPFieldLookupValue oldLookupValue = new SPFieldLookupValue(properties.ListItem["LookupColumn"].ToString());

SPFieldLookupValue newLookupValue = new SPFieldLookupValue(properties.AfterProperties["LookupColumn"].ToString());

if(oldLookupValue != newLookupValue)
{
     //look up column value has changed
}

The above code looks correct, but simply would not work in "ItemUpdating" event.

Reason:

Value of properties.ListItem["LookupColumn"].ToString() will have the correct look up value like "3;#karthik", but the value of properties.AfterProperties["LookupColumn"].ToString() will have only "3" (just the look up ID).

Resolution:

Here is the workaround that I implemented to get around this issue:

string oldLookupValue = (properties.ListItem["LookupColumn"] == null) ? "" : properties.ListItem["LookupColumn"].ToString();

string newLookupValue = (properties.AfterProperties["LookupColumn"] == null) ? "" : properties.AfterProperties["LookupColumn"].ToString();

int oldLookupID = 0;
int newLookupID = 0;

if (!string.IsNullOrEmpty(oldLookupValue))//Get the old Lookup id
{
     SPFieldLookupValue oldLookup = new SPFieldLookupValue(oldLookupValue);      oldLookupID = oldLookup.LookupId;

}
if (!string.IsNullOrEmpty(newLookupValue))//Get the new Lookup id
{
     newLookupID = Convert.ToInt32(newLookupValue);
}

if (oldLookupID != newLookupID)//Lookup has been updated
{     //value has changed

}

Another solution would be to use string parsing methods to compare just the ID part.