I have discussed this topic also in Deep Dive into the SharePoint Content Deployment and Migration API - Part 7 but as this is an important topic for everyone - not only people coding against the Content Deployment and Migration API I though to post it also using a headline that will catch the eyes of people developing Event Handlers and Feature Activation code.
In MOSS 2007 we often had support calls where content deployment failed due to event handlers firing and updating content during import.
Event handlers or feature activation code which modifies site content on the target system can cause all kind of issues:
To overcome this problem developers had the challenge to either detect that the event handler was fired in context of an import operation (which was not trivial) or a different version of the event handler code had to be installed on the target system to avoid performing the operations.
With SharePoint 2010 there is now a new class available (SPImportContext) which allows an event handler or feature activation code to detect easily if they are fired in context of an import operation or not.
On SharePoint 2010 all event handlers and feature activation code which modify content in the database can now (and should) implement a check of SPImportContext.Current.IsRunning to detect if the code execution is a side effect of an import operation or not.
That allows a developer to implement a separate code path in the event handler which avoids problems during import.
SPImportContext provides the executing code access to the following information:
Be aware that SPImportContext can only work for event handlers which execute on the same thread as the import operation. Asynchronous event handlers which are executed on a different thread cannot detect that they were invoked from an import operation. This affects especially the default "after events" which execute after a change has been performed. These event usually fire asynchronously on a different thread. "Before events" which fire before a change is done will always execute on the same thread.
There are two workaround for this issue:
Cool, thanks for the heads up... Useful info!
We have a site collection with variations. Each pages library has an event receiver that got activated when a new page is added. The event receiver checks with SPImportContext that the item is added via Import. When it is, it does some action. When it's manually created in the variation sub site, the event receiver does nothing.
This same site collection should be exported via Content Deployment. In the case, the event receiver shouldn't do any actions when a new item is added.
How can we handle this "paradox"?
either have a different Version of the Event Receiver on the Import target of Content deployment or you would Need to evaluate the current callstack rather than using SPImportContext to understand if the Import is done by Content deployment or by variations.
sample for stackwalk: