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:

Can cause deadlocks with conflicting with the import operation

Might create new items which will are also included in the package being imported causing import to fail later with GUID conflicts.

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.

SPImportContextprovides the executing code access to the following information:

If the current method is called as side effect of an import operation (IsRunning)

If the import is performed with RetainObjectIdentity (RetainObjectIdentity)

If the import operation is currently in the process to fix broken lookup columns (FixingBrokenLookups)

The status of the Import operation (Status)

Limitation

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.

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.

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.