Retrieving the Source Term for an items field.

I’m working on a project where I needed to get back to the term properties for various fields of a SPListItem that are based on a managed metadata column.

The actual process of getting back to a fields source term turned out to be rather simple, as the TaxonomyFieldValue object gives you everything you need.

I thought others might find this useful, so I present my GetTerm method here. This sample is provided as an Extension method, but you certainly can use it standalone if you wish.

using System;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Taxonomy;

namespace krichie.ExtensionMethods
  public static class Extensions
    /// <summary>
    /// Retrieves the Source Term for an items field.
    /// </summary>
    /// <param name="item" />The item to inspect</param>
    /// <param name="fieldName" />The name of the field</param>
    /// <returns>The Taxonomy term</returns>
    public static Term GetTerm(this SPListItem item, string fieldName)
      Term term = null;
      TaxonomyField field = item.Fields[fieldName] as TaxonomyField;

      // if this is not a TaxonomyField throw a new exception
      if (field == null)
        throw new Exception(fieldName
          + " is not of type"
          + " Microsoft.SharePoint.Taxonomy.TaxonomyField.");

      TaxonomyFieldValue value = item[fieldName] as TaxonomyFieldValue;
      if (value != null)
        TaxonomySession session =
          new TaxonomySession(item.ParentList.ParentWeb.Site);
        if (session.TermStores.Count != 0)
          TermStore store = session.TermStores[field.SspId];
          TermSet set = store.GetTermSet(field.TermSetId);
          // Get the term using the distinct TermGuid.
          // If you were to just use set.Terms[fieldName],
          // you would only examine the root of the term set.
          term = set.GetTerm(new Guid(value.TermGuid));
      return term;


– Keith

EventReceiver firing twice? Don’t make this bone headed mistake!

So for the past week or so I’ve had this looming issue hanging over my head that I would try to nail down in-between other issues that I swear was going to be the death of me.  I knew whatever it was had to be something really simple that I kept overlooking and something that, when I finally figured it out, would be quite elemental.

The problem was that I had written an EventReceiver to handle ItemAdded events for a custom list.  The handler simply creates a task in the Tasks list corresponding to the new item added to the custom list.  Every time an item was added to the custom list, the event was firing twice.  I was associating the event receiver to the custom list through FeatureActivated on a feature receiver for my Event Receivers project.

I had already covered all the basic things such as:

  • Ensuring I set EventFiringEnabled = false
  • Ensuring that Require Check Out wasn’t the cause
  • Ensuring that my handler code wasn’t actually adding back to the list Smile
  • No, the event receiver association wasn’t applied via a site template.  This was a UI created site, and the list was not generated from a template either.

I even went as far as completely emptying the body of the handler to see that in fact the event was firing twice.

As with any problem, I always try to  resolve it through the process of elimination by first isolating the core issue into a test project and therefore out of the primary project I’m experiencing it in because sometimes you can’t see the forest because of the trees.  This particular problem was no exception.

After creating the simple project, the problem was still there.

Even a simple app to enumerate the event receivers associated to the list only showed the one instance.  It was crazy.

Well, I had moved on to other things again, when all of a sudden, I noticed that new tasks were being created in the task list for some documents that I was uploading to a different document library.  Aha! Now I had something else to go on.  The event wasn’t firing twice for the same list, it was firing for ALL Lists.  That’s pretty much the symptom for a receiver associated to a list template, but this was NOT a list template!

Then it dawned on me.

I took another look at my project.

I took another look at my event receiver I had added via Visual Studio to the project.

Then I realized the mistake I had made.

Yes, I had left the elements file for the Event Receiver there, and therefore when the feature was activated for the project, the receiver got associated to ALL lists on the site.  It wasn’t going to show up in the EventReceivers collection for that list instance, because it was associated to the list type.  When I added it to the list instance, it just caused the event to fire twice on THAT list. <facepalm>

I could have just removed the elements file reference from the feature, but just chose to delete the elements file in its entirety.  I didn’t need it.

So folks, when you create an event receiver via the SharePoint tools in Visual Studio, and you REALLY don’t want it associated to every single list, remember not to be a bone head like me.

I knew the problem was elemental, I just didn’t realize how elemental it was.

– Keith

Bráthair! Chi mi dh’aithghearr sibh!

Am màireach is going to be a deagh latha!

It’s the first time this year my good friend, my Bráthair at heart, Jon and I are going to be at Scarborough together.



When he and I get together out there, it’s ALWAYS a good time Smile.

Jon and his wife welcomed their beautiful daughter into the world last year, so naturally it’s not as easy as it was to just “Hook up” out there any time we wanted.  But everything is squared away for tomorrow, and I don’t know who in our group is more excited than the other.  We’re all pumped!  Tha mi sona!

Oh and I’m sure there will be more than enough embarrassing pictures Smile.  We’ll just have to decide which ones make it out into the public Smile.

Chi mi a-rithist sibh!

– Keith

[Update] – 05-11-2011

Figured I would share a few pictures of the event with my Bráthair:


It was a blast Smile

Categories Uncategorized