This post is part of a series on SharePoint 2010 Managed Metadata. The other posts in this series can be found here: SharePoint 2010 Managed Metadata
Creating columns on a SharePoint list is fairly straightforward for most folks as the browser is such an easy option. Another creation option is SharePoint Designer 2010. However in both of these scenarios the creation of the columns is not very portable. These columns are only going to live within the confines of the list you created them within. Be forewarned!
What about the situations where you want to have a more repeatable scenario in creating the columns of type Managed Metadata? In these cases you want to get everything boxed up in a package (*.wsp). The only way to do this is to either create the column declaratively or programmatically. However there can be issues with this approach.
First, look at your two options. You can create site / list columns in a repeatable fashion using the object model typically either in a Feature receiver or maybe as a PowerShell Script. The other option is to create the column using the Feature schema (XML). Both options have their advantages and disadvantages. I’ve had some great conversations watching folks go back and forth on the merits of a declarative vs. programmatic approach.
Wictor Wilen (here & here) and Ari Bakker (here & here) have written a good bit about this subject. Now I’d like to give you my opinion. Generally speaking I prefer to create columns declaratively. However I found quickly that you couldn’t do a 100% pure declarative approach when creating Managed Metadata columns. You always had some extra work to do to clean up links to the term store and term set the column was attached to. Sure, in many instances you could define these values in XML, but it always felt like an exercise that was “do it only in XML for the sake of doing it” not because that is what made sense. Most of the time I found I needed to add some logic around getting the term store or term set and not just specifying some ID. This is demonstrated in both Wictor’s and Ari’s posts… they both show how to create the columns declaratively and then have some code do the extra work.
However I’d like to offer another approach. Instead of doing it declaratively, why not do the whole column programmatically? When you create the column programmatically you don’t have any extra work to do like creating the note field or the other hidden fields. When you create the Managed Metadata column programmatically, SharePoint handles all the other creation of the hidden fields and wiring up tasks. There’s no extra work that you have to do as is shown in both Wictor’s and Ari’s posts.
For instance, consider this code creating a new column on a list:
Create a Managed Metadata Field
Now using the Server Explorer tool window in Visual Studio 2010, notice the other hidden columns were created for us. Here are the two event receivers automatically added to a list:
Event Receivers Automatically Added
And here are all the fields (#1 is what I created in code, #2 & #3 are the new hidden fields):
Location Tag
Taxonomy Catch All Column
If you need some more info on these hidden fields, check out my other post on the subject
Perfect… exactly what we wanted! Now I too wish there was a declarative only way to do this but fact is there just isn’t. So for now, this method works just fine for me and doesn’t require any extra work to do what SharePoint should already be doing for us.
Microsoft MVP, Full-Stack Developer & Chief Course Artisan - Voitanos LLC.
Andrew Connell is a full stack developer who focuses on Microsoft Azure & Microsoft 365. He’s a 20+ year recipient of Microsoft’s MVP award and has helped thousands of developers through the various courses he’s authored & taught. Whether it’s an introduction to the entire ecosystem, or a deep dive into a specific software, his resources, tools, and support help web developers become experts in the Microsoft 365 ecosystem, so they can become irreplaceable in their organization.
