Author / Simon Doy

Unknown's avatar

Posts by Simon Doy

I am an avid SharePoint enthusiast who works as an Independent SharePoint Consultant based in Leeds, United Kingdom. I am one of the organisers of the Yorkshire SharePoint User Group in the United Kingdom. I have been designing and building SharePoint solutions since 2006.
by Simon Doy

SharePoint Utility to manage Content Type and List Event Receivers


Introduction

Recently I have been building a solution which makes use of Content Type Event Receivers. The event receivers were being deployed using declarative xml for example:-

<ContentType ID=”[Removed]” Name=”My Content Type” Group=”My Content Types” Version=”0″>
<DocumentTemplate TargetName=”/_layouts/CreatePage.aspx” />
<XmlDocuments>
<XmlDocument NamespaceURI=”http://schemas.microsoft.com/sharepoint/events“>
<Receivers xmlns:spe=”http://schemas.microsoft.com/sharepoint/events“>
<Receiver>
<Name>MyEventHandler</Name>
<Type>ItemUpdated</Type>
<SequenceNumber>10000</SequenceNumber>
<Assembly>MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=000000000000</Assembly>
<Class>MyAssembly.EventReceivers.ContentTypeEventReceiver</Class>
<Data></Data>
<Filter></Filter>
</Receiver>
……

Now this normally works great, except when you make a mistake. Its quite well known that upgrading Content Types that have been defined using declarative xml can be tricky.

This is one of the reasons why Microsoft released Feature Upgrades in SharePoint 2010 (if you haven’t seen this then please check out Chris O’Brien’s set of blog posts (http://www.sharepointnutsandbolts.com/2010/06/feature-upgrade-part-1-fundamentals.html) on the subject).

In this case the development was on a SharePoint 2007 environment and I found myself in a situation with deploying Content Type Event Receivers.

It seems that once the Content Type had been deployed and the feature switched on its quite difficult to make certain changes to the content type. This includes changes like the following:-

  • changing a field’s default value
  • changing whether a field is required
  • changing the event receiver definition
    However, unfortunately Gary LaPointe’s stsadm commands would not working correctly for my content type and Gaetan Bouveret’s utility only manages list event receivers but does look very good at that!

Solution

Therefore I started to write my own command line utility. The first version was quickly written to get what I needed to do, done.

I have updated it so that at least its a bit more intuitive but it still only allows you to modify event receivers at a content type or list level.

Please be careful because if you ask it to delete an event receiver then guess what it will delete the event receiver!

As with all these utilities please do not try using this on your production environment without performing some testing on a development environment beforehand.

If you have any comments, problems with the utility please leave a comment and I’ll take a look..

Utility System Requirements:-

  • SharePoint 2007 SP2 (Tested on April 2010 and April 2011 Cumulative Update)
  • Utility must be run from machine which is connected to the SharePoint farm that is being modified.

Usage:-

Console application name: ITSP.EventReceiverConfig.exe

Command Line Arguments:-

  • -url : full url of site that hosts content type or list
  • -mode : [list | add | remove]
  • -targettype : [list | contenttype | assembly]
  • -targetname : [name of list | name of content type | name of assembly]
  • -assembly : [full assembly name including version number etc]
  • -class : [fully qualified class name that is implementing the event receiver]
  • -type : [itemadding | itemadded | itemupdating | itemupdated]
  • -sequence : [number bigger than 1]

The utility with releases, document and source code can be found on Codeplex.

Codeplex Project: http://itspeventreceiver.codeplex.com

Documentation can be found here: http://itspeventreceiver.codeplex.com/documentation

by Simon Doy

SharePoint Feature Receiver token replacement only works with Guids using lower case characters


Introduction

This week I have been writing my first proper SharePoint 2010 Service Application.

Part of that solution is using a Feature Receiver to install the various components that make up a Service Application. These include:-

  • Service
  • Service Proxy
  • Service Application
  • Service Application Proxy
  • Service Instance

Tip: Andrew Connell’s chapter in the Real World SharePoint 2010 book is an excellent resource for getting the plumbing of the service application setup.

One of the issues came about at deployment time. Now that I write this, I do remember hearing about this issue before when during a SharePoint 2010 Developer Bootcamp. Of course I didn’t take enough notice and then hit the problem when I decided to update the GUID for the feature receiver.

The following error was displayed when deploying the solution:-

Error occurred in deployment step ‘Add Solution’: Failed to create receiver object from assembly “ITSP.SPMonitoringStatusPackage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=de085cbd57463aa2”, class “$SharePoint.Type.edd0669b-2393-4fe6-988d-17a2De06c6e4.FullName$” for feature “ITSP.SPMonitoringStatusPackage_ITSP.SPMonitoringStatusInstaller” (ID: a5ede1b3-cbd6-4918-9f31-4322603295f5).: System.ArgumentNullException: Value cannot be null.
Parameter name: type
at System.Activator.CreateInstance(Type type, Boolean nonPublic)
at Microsoft.SharePoint.Administration.SPFeatureDefinition.get_ReceiverObject()

Screenshot:-

guid-featurereceiverdeployerror

The deployment show that any error occured because it could not create a feature receiver object from assembly “ITSP.SPMonitoringStatusPackage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=de085cbd57463aa2” with the class “$SharePoint.Type.{GUID}.FullName$”.

The token, “$SharePoint.Type.{GUID}.FullName$”, should be replaced by Visual Studio as part of the build process. However this does not seem to happen with the GUID value that I was using (see below).

In this example the {GUID} value is specified against the feature receiver class using an attribute as below (please note the capital letters have been added for this example):-

guid-featurereceiveruppercase

The item that uses this GUID attribute for the Feature Receiver Class can be seen by double-clicking on the feature Visual Studio SPI object:-

featureceiver-spi

If you then look at the properties of the feature Visual Studio SPI object, you see the section as below:-

featureceiver-spi-properties

As you can see the Receiver Class has a value of:-

$SharePoint.Type.edd0669b-2393-4fe6-988d-17a2De06c6e4.FullName$

 

Solution

The issue is that upper case characters are being used and changing these to use lower case alphabetic characters for the GUID fixes the issue.

The following changes need to be made.

  1. Change the Feature Receiver’s GUID attribute.
 1: [Guid("edd0669b-2393-4fe6-988d-17a2de06c6e4")]

 

 2:     public class ITSPSPMonitoringStatusInstallerFeatureReceiver : SPFeatureReceiver

 

2. Update the Feature Receiver Visual Studio SPI object’s Receiver Class property to:-

featureceiver-spi-properties-fixed

Save all the files, rebuild, deploy and the solution is deployed successfully, hurrah!

feature-installed-successfully

 

Hope that helps.