5

My company ships a product that among other things registers SharePoint EventReceiver on SPLists, monitoring for changes. I've been registering it in the GAC where it runs just fine. However, one of our customers has expressed unhappiness with our assembly being installed in the GAC and wishes us to move our binaries to the SharePoint BIN directory and do the other security/trust voodoo that is required for that scenario to work.

When I try to register an event receiver that is not in the GAC, I get the very specific exception whose message reads: "The event receiver assembly is not in the GAC." I interpret this as SharePoint requiring event receivers to be installed in the GAC. Furthermore, I found this on MSDN: http://msdn.microsoft.com/en-us/library/ff407965.aspx: the section "Event Receivers and Handling Events" states

SharePoint Foundation event handlers are a compiled module of custom managed code whose invocation is triggered by a specified event that you have specified. Event handler code is compiled into a .dll file and deployed to the GAC.

This again implies but does not full-out state that the GAC installation is a requirement. Does someone know the answer for this for certain, so I can go back to the customer and explain our GAC requirement?

The followup question is now: if I have an assembly in the GAC, and I "statically link" to other assemblies -- i.e. I don't explictly dynamically load them with Assembly.Load() -- then those other assemblies must also reside in the GAC?

John Källén
  • 7,551
  • 31
  • 64
  • Just have to lol at "...one of our customers has expressed unhappiness with our assembly being installed in the GAC..." I can't think of a valid reason why one would be unhappy with assemblies being in the GAC. Isn't that better than being in the file system and requiring "security/trust voodoo"? – Tundey Jan 07 '11 at 14:03
  • Yeah, we were a little boggled ourselves when that requirement was revealed to us. I'm looking for any evidence I can provide them to make them reconsider their non-GAC policy. – John Källén Jan 07 '11 at 15:03

2 Answers2

11

Event receiver assemblies cannot be installed only in "bin", because this way the .net framework could not find them.

When your assembly is loaded from "bin" it is because assembly loader uses probing to locate the assembly. First it looks in GAC, then looks for directory called "bin" under the current working directory.

Hence all code you use to run the web interface - codebehind for ASPX pages, web services etc, can be placed in inetpub..../bin because the working directory of your web application is there.

However, workflows and scheduled "timer jobs" are executed by the OWSTIMER.exe, which is a Windows Service. As a typical windows service, it has its working directory somewhere in c:\windows.

It means, if you place your assembly somewhere in inetpub...\bin, it will not be found by the owstimer.

Hence, shared assemblies like event handlers have to be deployed to GAC.

naivists
  • 32,681
  • 5
  • 61
  • 85
  • Thanks, that makes sense. My customer would probably be less thrilled by having us putting our assemblies under c:\windows. – John Källén Jan 07 '11 at 15:05
0

Deployment of SharePoint EventReceiverwould not be possible in Bin. it has to be done in GAC only. I'm not sure what the exact reason is but may be it has to do something with code security.

Ashutosh Singh-MVP SharePoint
  • 5,283
  • 5
  • 26
  • 42