Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have a SPItemEventReceiver on a SharePoint library which renames added files. Normally this works fine (Upload from website / WebDav).

There is also a report server subscription which drops pdf's into the Library. In this case the event receiver doesn't fire at all. I tried ItemAdded and ItemAdding... no luck.

Any ideas?

share|improve this question
add comment

1 Answer 1

Just came across this exact same problem yesterday, and found your post while searching for an answer myself. I have a SQL Report that has a subscription that publishes a PDF, Excel, and MHTML file to a document library. That document library has an event receiver that does something to those files when they get published. The event receiver runs fine when a file is either added or updated using the SharePoint UI, but not when the subscription runs.

After giving this some thought I figured maybe the event receiver doesn't run in the context of the SharePoint web application. I tried setting a breakpoint in my event receiver and attaching the debugger to the OWSTimer service, which didn't yield anything, and then I tried again attaching it the SQL Reporting Service application, which in turn hit my breakpoint. My problem was that in my event receiver code I used the following code:

ConfigurationManager.AppSettings["AppSettingsKey"]

When the event receiver runs in the context of SharePoint, it checks the web.config for the appSettings key. When this runs in the context of SQL Reporting Services it checks this file:

Program Files\Microsoft SQL Server\MSRS10_50.LYNC\Reporting Services\ReportServer\bin\ReportingServicesService.exe.config

Because I only deployed my appSettings to the web.config for my site, the event receiver fails. I had to change the approach I use to pull up my configurable variables. At first thought this seems like a ridiculous approach to implementing event receivers, but after more thought it makes sense. For Reporting Services to publish a file, it would use the SharePoint API and call the method:

SPFileCollection.Add()

which at some point would need to check if there were event receivers which needed to be fired, both synchronously and asynchronously. Because the code is running in the context of the external application, in this case Reporting Services, everything in that methods code needs to be locally accessible by the calling application.

Long and short of this, if you coded your event receiver correctly and it fires in SharePoint but it doesn't appear to be firing from Reporting Services, make sure the DLL is GAC deployed, not in the bin folder, doesn't use web.config values in the code, and doesn't try to access anything that the SQL Reporting Services Service Account doesn't have access to.

Good Luck!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.