关于内容类型的几个问题：

So a couple of issues regarding content types:

首先，内容类型有两种：网站内容类型和列表内容类型。网站内容类型是驻留在库中的模板。在列表中使用网站内容类型时，该内容类型将实例化为给定列表中的列表内容类型。

First of all, content types comes in two flavours: Site content types and list content types. Site content types are "templates" that reside in a gallery. When a site content type is used in a list, the content type is instantiated as a list content type on the given list.

第二，可以创建您的内容类型并可以通过几种方式进行修改，这将决定数据库中数据的三种模式。

Secondly, your content types could be created and modified in several ways, which would decide in what of three modes your data is present in the database.

如果使用GUI或通过自定义创建了内容类型使用API​​编写代码，您的网站内容类型和列表内容类型都处于数据库中的仅数据库状态。这意味着它将在数据库中寻找内容类型的定义。

If you have created the content type using the GUI, or through custom code using the API, both your site content types and your list content types are in the "database-only" state in the database. That means that it is looking in the database for the definitions of the content type.

如果您已经在 CAML ，您的 site 内容类型已被重影（或未自定义，因为我们应该将其称为v3）。从根本上讲，这意味着数据库在12单元格中的功能XML中查找构成内容类型的站点列。因此，这意味着您可以更新功能，并且在更新内容类型中可以使用新的网站列，对吗？

If you have created the content type as a feature in CAML, your site content type is ghosted (or un-customized as we are supposed to call it in v3) in the database. That basicly means that the database looks in the feature XML in the 12-hive for the site columns that makes up the content type. So that should mean that you could update the feature, and you would have new site columns available in the update content type, right?

不幸的是：还记得我们还有列表内容类型吗？令人讨厌的是，这些列表内容类型是使用代码实例化的，因此它们处于仅数据库状态。这意味着您所做的更改只会显示在您的网站内容类型中，而不会显示在使用该内容类型的现有列表中！

Unfortunately not: remember that we also had list content types? The bummer here is, that these list content types are instantiated using code, so they are in the "database-only" state. It means your changes would only be seen in your site content types, but not in existing lists using that content type!

有几种方法可以解决此问题，即解决方案取决于您的需求和所做的更改（删除字段，添加字段，更改字段）。

There are several approaches to fixing this issue, the solution depends on what your needs are and what kind of changes you are doing (deleting fields, adding fields, changing fields).

例如，即使内容类型随时间变化，您通常仍希望保留现有的商品元数据。如果通过代码推送列表内容类型中的更改，则会丢失存储在已更改/已删除字段中的数据。一种解决方案是在旧内容类型的基础上添加一个全新的内容类型，但要更改字段。您将添加新的内容类型（通过代码或使用功能XML），并使用功能接收器或类似功能将新的内容类型传播到所有使用旧内容类型的列表中，然后将旧内容类型标记为隐藏。这样就可以保留旧的元数据，而不必使用除新的元数据以外的其他项来添加新项。

For example, you would often want to keep your existing item meta data, even though the content type changes over time. If you push through the changes in the list content type through code, you would lose the data stored in the changed/deleted fields. A solution to this would be to add a completely new content type based on the old one but with the changed fields. You would add the new content type (through code or using feature XML) and use a feature receiver or similar to propegate the new content type to all lists that used the old content type, and subsequently mark the old content type as hidden. That would make it possible to keep old meta data but not to add new items using other than the new meta data.

该问题的其他答案中提到的方法将是如果您可以直接访问生产环境，并且在客户治理计划允许的情况下为首选。但是，与SharePoint中的其他工件一样，建议以结构化的方式部署内容类型。以非结构化的方式添加新的内容类型将影响搜索的相关性（托管属性），并且还可能影响网站的一般分类法（网站列未重复使用等），因此即使可以将这些更改直接添加到网站中生产站点，我不会推荐它！

The approach mentioned in the other answer to this question would be preferred if you have direct access to the production environment, and if your customers governance plan allows it. As with other artifacts in SharePoint however, it would be recommended to deploy content types in a structured manner. Adding new content types in an unstructured fashion would influence search relevance (managed properties) and could also affect the general taxonomy of the site (site columns not being reused, etc.), so even though it is possible to add these changes directly in a production site, I would not reccomend it!

这使我进入了我将推荐的最终方法，至少对于将来的内容类型是这样：创建您的内容类型从一开始就使用功能接收器进行编程！这样，您将始终了解内容类型的真实状态（仅数据库），并且可以采用结构化的方法来管理将来的更改！通过谷歌搜索以编程方式创建内容类型 SharePoint，您可以找到几种方法。

That leads me to the final approach that is the one I would reccomend, at least for future content types: Create your content types programmatically from the beginning using a feature receiver! That way you always know the true state of your content types (database-only) and you can have a structured approach for governing changes in the future! You can find several ways to do this by googling 'create "content types" programmatically SharePoint'

出于完整性考虑，我提到了三种模式。您的内容类型可以进入的最后一个模式是 UnGhosted。这意味着您的内容类型是使用功能XML创建的，但已与12个配置单元中的原始XML源断开连接。

For completeness: I mentioned three modes. The last mode your content type can be in is "UnGhosted". This means that your content type was created using feature XML, but that it has been disconnected from the original XML source in the 12 hive.

我的朋友SørenNielsen有一些不错的选择 审核您的内容类型层次结构中的内容类型
/ em>。可以在MSDN文章 更新中简短地提到上述一些问题。内容类型 。
Gary Lapointe还具有STSADM扩展名，可解决内容类型的某些问题，请参见 传播内容类型更改 。

My friend Søren Nielsen has some good points on Content Types in Audit your Content Type Hierarchy. Some of the issues described above can be found briefly mentioned in an MSDN article Updating Content Types. Gary Lapointe also has an STSADM extension that addresses some of the problems with Content Types, see Propagate Content Type Changes.

对不起，但主题很复杂，要求详尽的解释以避免任何误解。

Sorry for the rant, but the subject is complex and demands a thorough explanation to avoid any misconceptions.