I have a feature (Web scoped) with a content type which contains a field (Type="Choice").

Values were A, B and C.

I've created a list based on this content type and added some elements in it.

I then added the choices D, E and F and changed the version of the feature.

I updated the solution and performed an upgrade on the feature with $feature.Upgrade($false).

I can see the changes at the Web level (content type has changed, field has changed) but the one in the list instance NOT. When I add a new element to the existing list it only shows choices A, B and C. If I create new lists based on the content type they show the now A, B, C, D, E, F choices.

How can I propagate the change into the old list so that the field shows all choices (A, B, C, D, E, F) when creating new elements?

1 Answer 1


Looks like you're using default Update method of SPContentType when updating your content type in feature updating receiver.

To push changes to all inherited list content types, you should use another overload of the Update method, and pass true to it:


Description of the parameter from MSDN:


Type: System.Boolean

true to push the changes made to the content type down to content types that inherit from it; otherwise, false.

Also you can check out this rather descriptive post from Charles Chen on the topic:


In this particular situation, turned out, that you don't need to update the content type at all, since it hasn't been changed itself. The point is, that Content Types in SharePoint does not include fields definitions, they include only FieldRefs, i.e. links to existing fields.

So, if you change some properties in underlying site field, the content type keeps unchanged, and you need to update the field rather than the content type.

And with fields, the same situation with overload is in place: use SPField.Update(Boolean) overload and pass true to it to update the field and propagate the changes to all implementations of the field.

Description of the parameter from MSDN:


Type: System.Boolean

true to propagate changes to lists that implement the field; otherwise, false.

  • Thanks for pointing this out to me (+1). Tried to do an Update on the content type but it didn't work (as a guide to others, you have to get your content type from ContentTypes not from AvailableContentTypes which is read only :D). But it worked when I tried this on the field: $my_web.Fields["my_field"].Update($true). When should contentType.Update() be used and when field.Update()? When should both be used?
    – JohnDoDo
    Commented Oct 27, 2011 at 8:04
  • 1
    Ah, got it! Quite obvious: if you have site field, and you make changes to the definition of this field - you should use field.Update(). contentType.Update() should be used then you remove/add field to the content type. So if you made changes to a site field, content type actually haven't changed itself, because you have only a field link to the field in it. Commented Oct 27, 2011 at 8:34
  • Yes, it makes sense, I understand now. Could you please incorporate this into your answer so others can find the information more easily? I'll then mark it as accepted. Thanks a lot!
    – JohnDoDo
    Commented Oct 27, 2011 at 8:48
  • You're welcome! Feel free to ask any further questions :) And yes, I've updated the post as you recommended. Commented Oct 27, 2011 at 9:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.