I'm a n00b with SharePoint and find myself looking at a solution where there seems to be a lot of redundant field/column definitions. Is this a necessary evil or is it just SP being tolerant of bad practice?

For example, I may find a field defined as a site column, then find the same field (the ID has the same GUID value) in many content types, and also in multiple lists. In content types it is clear that the manifest (Elements.xml) is in fact just making reference to a field, since it uses the FieldRef tag, but elsewhere (Elements.xml for site column, Schema.xml for lists) it looks to me like basically the same thing is being defined over and over again.

Even in the content types, where it's explicitly a reference, I still find the same definitions as elsewhere, e.g. the type, group, displayname and so on are all repeated.

It makes sense to define some aspects of the field in the context where it is used. For example, Customer may be a required field in the Order content type, but perhaps optional in the Feedback content type. Likewise it may be sensible to override the displayname in some contexts.

But putting that to the side, assume I wish to have only one field definition, including a default displayname.

May I define the site column and refer to it with nothing more than ID in lists and content types? (In practice I suppose I will make name redundant as it is very unfriendly to have only the GUID to go by.) So that if I want to, say, modify the (default) display name, I can do this in ONE PLACE?

1 Answer 1


Yes, this is a necessary evil (one of many) when dealing with declarative SharePoint solutions that include list definitions.

If you think that's bad, wait until you need to provision a lookup column.

If deploying actual code is a possibility for you, I would strongly suggest considering that for provisioning elements to SharePoint. For example, you could build out your fields, content types and lists in a feature event receiver. This approach mitigates a lot of the pain points found in declarative provisioning, and it's where the future of the SharePoint development model is headed. It will also make your upgrade path smoother if that's a consideration.

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.