SharePoint Event Sinks and Strong Names | Jesse Fewell SharePoint Event Sinks and Strong Names – Jesse Fewell

SharePoint Event Sinks and Strong Names

By September 25, 2006Blog, Uncategorized

A Microsoft SharePoint document library will allow you to provide your own logic to execute whenever a user does something in that library. For example, you may want to add a property to the document, based on certain business rules. The examples and instructions provided by Microsoft are pretty handy, but neglect to give one critical piece of advice: Use auto-versioning everywhere.

By default, Visual Studio 2003 creates an AssemblyInfo.cs file that defines your assembly’s version number as follows:
[assembly: AssemblyVersion(“1.0.*”)] This tells the compiler to generate a new version number on the assembly, anytime any change has been made either to your code, or to a dependency library. You really should keep this as-is. If your assembly is always set to version 1.0.0, then when you go to install a new build of that assembly into the GAC, SharePoint will never bother to reload the assembly. Even if you re-specify the same assembly name in the Document Library Advanced Settings, SharePoint will think it has already loaded the library into memory. However, if each new build has its own version number, exactly that build will be loaded into the GAC, exactly that build will be specified in the Event Sink Advanced Properties, and exactly that build will be loaded into SharePoint memory.

But what if your assembly depends on a helper library, like a business layer? Then you need to stronly name that library as well, and install that library into the GAC, so your Event Sink assembly can find it. If your dependency library has a hard-coded version number like 4.3.0, then you’ll have the same problem with new builds. Once you load a newer version of that library into the GAC, it will not be loaded into SharePoint memory, because SharePoint thinks it already has it. Instead, you should use the same “auto-versioning” directive in the AssemblyInfo.cs for that dependency library. This way, all changes are explicitly versioned, forcing you to specify that version in the Event Sink settings, and explicitly forcing SharePoint to loaded exactly that version of the dependency library.