SharePoint 2010 event receiver–The ins and outs

22. July 2011 06:57 by tal in   //  Tags:   //   Comments (0)

So you wants to add an event receiver to a list to check column permissions. Your immediate reaction will be “easy no problems, I’m keen to start now”. Consider all the implication of this task. I thought initially, event receivers in SharePoint 2010 should be easy to implement. But then I learned that there are many “things” to know for this task. I decided to prepare a list with all the road blocks I encountered during this project.

Here are some tips for creating a new event receiver in SharePoint 2010:

1. There are lots of information about creating an event receiver SharePoint 2010.

2. You want your receiver to work on a specific list, not on a list type.  Your element.xml should fix it:
<Receivers ListUrl="<List Name>">

3. You want to make sure that the receiver is deployed as a farm solution. If we select Sandbox solution, this option is very restrictive and does not allow access to certain SharePoint features. So click on your project and view the properties window (F4). Then set “Sandbox solution” to “False”.

Also if you want to deploy to a single site use “Site URL” in the properties menu.

4. To deploy and package your solution you can use “Deploy” and “Package” in the Visual Studio 2010 on project’s right click.  Do not use the WSBuilder sub menu.

5. To debug use the WSBuilder sub menu and select “Attach to IIS Worker Process”, then enter your breakpoints.

6. I wanted to make sure that system admin have full permission:
using (SPWeb currentWeb = properties.OpenWeb())
{
        if (currentWeb.CurrentUser.IsSiteAdmin) return;
}

7. You want to add debugging information to your code. This is another reason why you should not use sandbox solution. Consider these quotes:
Dashboard diagnostics:  “Even if you use SPMonitoredScope, if your code is a sandbox component (i.e. a User Solution), the output from it will not be captured in Developer Dashboard.  The reason it doesn’t get captured is that sandbox components execute in a completely different process from the page request – that’s why it’s sandboxed
Log diagnostics: “Unfortunately the ability to interact with a custom SPDiagnosticsService is available only in fully trusted farm solutions and not within sandbox solutions. To write to the ULS logs using the SPDiagnosticsService class from the sandbox, developers can create a fully trusted proxy that the sandbox solutions can call into. The next two sections demonstrate how to write to the SharePoint ULS logs.”

But all is not lost, you can still save to SharePoint Log:
using Microsoft.Office.Server.Diagnostics;
PortalLog.LogString(“Message”);

8. The example I prepared is for firing an event when updating an item:
public override void ItemUpdating (SPItemEventProperties properties)
       {
           base.ItemUpdating(properties);

           TakeAction(properties);
       }

9. Sometimes you may need to active/deactive your feature from the site collection.

10. You definitely want to have a custom error page to indicate your user that something happened. You can learn how to create a custom error page  from here. For example:
properties.Cancel = true;
properties.Status = SPEventReceiverStatus.CancelWithRedirectUrl;
properties.RedirectUrl = "/_layouts/<folder name>/<>page name.aspx?error=Update failed.";

11. The message in DataSheet view is not as you expected. I have no solution for making a nicer error message.

12. Using the properties.AfterProperties you want to determine if the item has been modified during this update. Consider what I had to do to get the correct column:
string internalColumnName = XmlConvert.DecodeName(properties.List.Fields.GetField(columnName).InternalName);
if (properties.AfterProperties[internalColumnName] != null) newValue = properties.AfterProperties[internalColumnName].ToString();

Yes, there is a different name for the list column displays and the actual SharePoint column name. This is especially true if you rename an existing column The XMLConverter decode columns names , e.g. Date_x0020_Modified. This link has good explanation.

13. For security reasons, a SharePoint designer workflow always runs under the permissions of the user who started the workflow. You want to prevent the user from updating certain column in the list, but you also want your SharePoint Designer workflow to update the same columns. Two possible solutions, you can use a hidden field to indicate to the event receiver that the workflow is updating the field. You can toggle the hidden field before and after the item update. Another solution is to us user Impersonation Step and run the workflow as farm account. The second solution may not be your preference, because it will save the “Modified By” as the farm account.

These are the 13 new knowledge points which I gained during this project.

Enjoy.

Webcoda, SharePoint Consultants & Web Development

SharePoint Development Sydney is a crack team of SharePoint Consultants and SharePoint Developers.

We can't tell you their names or show their faces on TV but if you need a SharePoint job done right, call them on +61 2 9370 3602 or email us at info@sharepointsydney.com.au

Persecuted by the Government and shunned by society they developed their SharePoint skills in back streets and labor camps where other programmers wouldn't dare to tread. 

During a trek through the Himalayas they stumpled upon the fabled Mossy Yak who shared his SharePoint knowledge of how to attain Nirvana through a series of Workflows and Event Handlers. Their mission is to spread this knowledge through-out the world to bring peace, harmony and document version control to all .

 

Month List