SharePoint Event Sinks and Strong Names

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.

20 Years Of Agility: Reflections, Tough Questions & Surprising Answers

As we approach the 20th anniversary of the “Manifesto for Agile Software Development”, it’s time to ask some big questions: Are projects really any more successful these days? Have companies truly shed any of the bureaucracy? Are professionals actually feeling the empowerment we’ve been fighting for so long? And where are things headed in the next few years?

Leaders Lean Into Ambiguity

This past year has taught me one lesson over and over: people need clarity to do great work. Yet too often, we hesitate to be the ones to provide it. When the path forward is unclear, we hold back, waiting for someone else to step up. But here’s the truth: clarity...

YES, Racial Justice Matters at the Office

We are at an inflection point in the american conversation about institutional racism. As project managers, departmental directors, VPs, scrum masters, we have influence in that institutional system. Therefore, we have a professional obligation to create a safe space for our black and brown colleagues, during this crisis moment. Here are 5 things you can do to promote racial justice and equality at your office.