views:

1625

answers:

3

Howdy,

Still in the learning process with SharePoint.

We have an SPItemEventReceiver compiled into its own assembly.

We are using STSDev to package up a SharePoint solution with this EventReceiver as a feature. I am not assigning the SPItemEventReceiver to a specific ListTemplateId within the elements.xml, but am instead linking a ReceiverAssembly in the feature.xml and programmaticaly assigning the SPItemEventReceiver to multiple SPList items.

    public override void FeatureActivated(SPFeatureReceiverProperties properties)
    {
        foreach (SPWeb web in site.AllWebs)
        {
            SPListCollection webListCollection = web.Lists;

            foreach (SPList myList in webListCollection)
            {
                if (myList.Title == "Lab Reports")
                {
                    SPEventReceiverDefinitionCollection receivers = myList.EventReceivers;
                    SPEventReceiverDefinition receiver = receivers.Add();
                    receiver.Name = "PostUpdateLabReport";
                    receiver.Assembly = "LabReportEventHandlers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1111111111111";
                    receiver.Class = "LabReportEventHandlers.LabReportsHandler";
                    receiver.Type = SPEventReceiverType.ItemUpdated;
                    receiver.Update();
                    break;
                }
            }

            web.Dispose();
        }
    }

I am using FeatureDeactivating to do the reverse of the above code, removing the EventReceiver from the lists.

Question:

How should I handle the future event where LabReportEventHandlers is updated and the version changes?

These are the options I can think of:

  1. Deactivate / Reactivate feature -- I would wrap the updated dll back into the SharePoint solution file, change my code above to reflect the new version, and use stsadmin to upgrade the solution. I would then deactivate/ reactivate the feature.

  2. Add Assembly redirection to the web.config.

  3. Don't bump the LabReportEventHandlers version number.

Is there something in changing the solution version that will help me?

I think there are problems with the 3 options:

  1. After deactivation of the feature, someone could update an item before I can reactiave.

  2. I would not want to edit the web.config by hand, so I would use the sharepoint API instead. Where would I run that code?

  3. This is just plain wrong, but easy.

Hope you enjoy the question more than I enjoy SP. (SP and I have a love/hate relationship)

Thank you,
Keith

A: 

Hello,

I am not sure what you want with the upgrade, whether you want the new event handler to be applied to old lists or just for new lists.

For upgrading just new lists you could put the assembly information in a separate file, read that file in your FeatureActivated method, and apply the new values. When upgrading all you need to do is to update the separate config file and any new activation will use the new values and version numbers.

If you need to upgrade old event handlers you could do a similar procedure, but add the new feature receiver before you delete the old. If you do this in the same method the time between adding the new handler and removing the old will be minimal and the chance of anyone adding an item at that exact time is close to zero. If you want to go all the way to zero, you can hide the list or have an additional ItemUpdated event handler that checks to see if an upgrade is in progress and if so halts the update.

So, in short: For new lists, read assembly config from external file For old lists, add upgraded assembly info just before removing the old handler.

.b

Bjørn Furuknap
Bjorn, All existing lists as well as all new lists should use the same eventhandlers.
Keith Sirmons
In that case you have a simpler task. As mentioned, just have the featureactivated receiver read the config off a separate file and then add the new receiver before removing the old receiver. If you like I could post an article right after January 1st on how this can be done.
Bjørn Furuknap
Sure.. Articles are always fun to read.
Keith Sirmons
+1  A: 

Maybe you can encapsulate the logic that is prone to change into a separate assembly, that is referenced and used by your event handler. This way, the event handler itself won't change have to change, you would only deploy the updated "logic" assembly to the GAC or bin directory(ies) appropriately.

HTH, jt

Jason
Thank you for the suggestion. I will see if this can be done, but I am not responsible for developing the assembly, just deployment and integration.
Keith Sirmons
A: 

I only use assembly versioning if there's a need for both (old and new) versions of the assembly to be executed. I never needed this on an event receiver. Therefore, I don't change the assembly version for event receivers.

vitule