Triggering custom behavior, after sub-site (web) creation in SharePoint 2007, involved stapling a custom site feature to the site definition. SharePoint 2010 provides additional “web” events, which developers may bind custom event receivers and execute custom code.
Creating a new event receiver and binding to web events is a simple exercise in Visual Studio 2010 (Add a new event receiver item to a SharePoint project and specify the event).
I recently wrote a custom event receiver to provision content types in the Pages library of a publishing site at site creation – straight forward enough. Everything worked great inside the debugger, but after deployment, SharePoint would kick back a synchronization error, indicating a previous update had been made, during the provisioning process.
After some head scratching, I suspected that even though SharePoint fired the WebProvisioned event, the site provisioning process was continuing in the background. A breakpoint set on my catch block tipped me off because the pages library did not exist.
I consulted with a colleague, who made me aware of the following XML node in the event receiver Elements.xml file:
By default, SharePoint calls the WebProvisioned event asynchronously, without the above node in the Elements.xml file.
After a quick recompile and deployment (with the above node added), I was able to test sub-site provisioning working and my event receiver running each time without failure.