I recently build an event receiver for a document library that takes files added to a document library and republishes them to a different web application based on some custom rules. On a side note I used an event receiver and not the Drop Off Folder or a second SQL Reporting Services Subscription because it didn’t appear as though you could he Content Organizer Rules or subscriptions are sophisticated enough to publish to alternate web applications.
Anyways the event receiver was simple enough, and in testing when a document is added or updated, it was replicated to the correction location on the second web application perfectly. After deploying the event receiver I noticed that when my subscriptions ran and published the files to the document library the event receiver didn’t appear to fire, and the files were not replicated to the secondary location. I went back to my development environment and set up a similar subscription, set a breakpoint in the event receiver, and attached my debugger to SharePoint and waited for the breakpoint to get hit. Nothing!
I had to think about this for a bit and then realized that the subscriptions might run in a different service context. Sure enough they do, in the SQL Reporting Services context. So I attached the debugger to this process and the breakpoint was hit. My problem was 2 fold. First my code was using appSettings from the web.config to get a configurable variable for the second web applications URL. Because the code was getting executed in the context of SQL Reporting Service, appSettings was referring to the ReportingServicesService.exe.config appSettings and not my web applications web.config appSettings where I had deployed the settings. Secondly, I had use the SharePointLogger, part of theSharePoint Guidance Library to log errors to the ULS logs. Again because the code was executed in the context of Reporting Services, the service account that was used didn’t have permission to write to the ULS logs so I wasn’t seeing these errors in the logs.
A quick background on why the code is getting executed in the Reporting Services context and not SharePoint. Reporting Services is using the SharePoint API to publish the files. Specifically Reporting Services is using the API call, SPFileCollection.Add() to add the file to the document library. Internally in this method, the logic would need to check to see if there’s any event receivers on this list, and if so call the event receiver, either synchronously or asynchronously depending on the event in question. This is why the event receiver code needs to be generic enough that it can be run from any application that has the ability to call the SharePoint API, and also means event receiver code in DLL’s need to be GAC deployed.
