When it comes to content types the best practice is to define them up front and do not change them, but in real life this is not always practical. In my experience, when working with content types, at some point the client is going to want to change something whether it is a column or property on the content type. The problem comes when you want to deploy an updated version of this content type to many lists using it across the site. When deployed, if the updated content type definition was part of an existing list, the definition on that list would not update. One of the only ways to remedy this was to go into the UI and update the columns that way. This can potentially be very time consuming if you have a lot of site collections using the same list with the updated content type definition.
That was the issue with SharePoint 2007, let’s see how 2010 works.
To start I created a content type that inherits from “Document” with two dummy columns as you can see below. The idea that a content type definition at the site level and one at the list level can be different is an important distinction. As you can see in the image below the content type on the list inherits from the same content type at the site level.
First I want to try to add a new optional text field to this content type. This would seem like our best bet, because there would be no conflict with trying to remove existing fields that may have data in them. I was able to add an extra column to the content type, but the process wasn’t as straightforward as just updating the wsp (as I was hoping), it is more or less the same as updating the columns manually in 2007. I had to upgrade my solution, reactivate my feature, then navigate to my content type in the UI (it can be found easily through the list settings page) and add the column manually. I then got an error telling me the column already existed:
After selecting “Go back to site” this new column is part of any of the items using this content type:
It is interesting to note that I was able to add a Required field using this method as well. The field is not actually required until you try to save the item after the field is added.
To remove an existing column you have to use the UI as well. This time I will remove a column that an item of this content type has an existing value. If you go into the content type definition in the UI and select one of the columns you will see a button that will allow you to remove it along with some other properties:
If you keep the “Update List and Site Content Types” option as yes the column will be simply deleted from any inheriting content types (WARNING: you will lose this data). If you leave the option at “No” content types at the list level will not be changed.
So this process wasn’t updated in 2010 to allow updating content types that are in use via WSP. I believe this is as designed to limit the impact of a content type change on existing objects, but I was hoping that there might be a new property available on the content type definition that would allow this type of upgrade, but after spending time looking I don’t think it exists. It looks like I am going to have to stick to using a custom console application to update all of my content types.
That was the issue with SharePoint 2007, let’s see how 2010 works.
To start I created a content type that inherits from “Document” with two dummy columns as you can see below. The idea that a content type definition at the site level and one at the list level can be different is an important distinction. As you can see in the image below the content type on the list inherits from the same content type at the site level.
First I want to try to add a new optional text field to this content type. This would seem like our best bet, because there would be no conflict with trying to remove existing fields that may have data in them. I was able to add an extra column to the content type, but the process wasn’t as straightforward as just updating the wsp (as I was hoping), it is more or less the same as updating the columns manually in 2007. I had to upgrade my solution, reactivate my feature, then navigate to my content type in the UI (it can be found easily through the list settings page) and add the column manually. I then got an error telling me the column already existed:
After selecting “Go back to site” this new column is part of any of the items using this content type:
It is interesting to note that I was able to add a Required field using this method as well. The field is not actually required until you try to save the item after the field is added.
To remove an existing column you have to use the UI as well. This time I will remove a column that an item of this content type has an existing value. If you go into the content type definition in the UI and select one of the columns you will see a button that will allow you to remove it along with some other properties:
If you keep the “Update List and Site Content Types” option as yes the column will be simply deleted from any inheriting content types (WARNING: you will lose this data). If you leave the option at “No” content types at the list level will not be changed.
So this process wasn’t updated in 2010 to allow updating content types that are in use via WSP. I believe this is as designed to limit the impact of a content type change on existing objects, but I was hoping that there might be a new property available on the content type definition that would allow this type of upgrade, but after spending time looking I don’t think it exists. It looks like I am going to have to stick to using a custom console application to update all of my content types.
