SharePoint 中内容类型的最佳实践
最近，我们在生产农场中遇到了内容类型的严重问题。我想先解释一下这个问题的背景。
我们为生产和测试场中的内容类型安装提供了很好的工作功能。我们在 Visual Studio 中开发并部署（使用 wsps）此 SharePoint 功能。我们正在使用 发布页面使用页面布局和内容类型来帮助内容编辑者快速发布网页。不幸的是，某些内容类型和网站栏已由生产中的某些人手动更新/添加，因此每当我（开发人员）对现有内容类型进行一些更改（使用 Visual Studio 和功能激活/停用）时，SharePoint 都会删除一个或内容类型中的两列（在功能激活/停用期间）；或尚未以最佳实践方式添加的列。我认为最佳实践是使用 Visual Studio 更新内容类型。
现在，我希望确保在功能激活/停用时网站栏不应从内容类型中删除。
注意：我们的内容类型激活/停用功能在 feature.xml 中不包含任何激活依赖项
Recently, we came across a severe problem in production farm with the Content Types. I would like to explain the background of this problem first.
We have nice working feature for Content Types installation in production and test farms. We developed and deployed (using wsps) this SharePoint feature in Visual studio. We are using the publishing pages using page layouts and Content Types to help content editors to quickly publish the web pages. Unfortunately, some Content Types and site columns have been manually updated/added by some people in the production, so whenever I (developer) make some changes to the existing Content Types (using Visual Studio and feature activation/deactivation) , SharePoint removes one or two columns (during feature activation/deactivation) from Content Types; or the columns which have not been added in a best practice way. I think the best practice is to update Content Types using Visual Studio.
Now, I wish to ensure that site columns shouldn't get removed from Content Types upon feature activation/deactivation.
Note: Our feature for Content Type activation/deactivation doesn't hold any activation dependencies in the feature.xml
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
推荐方法
基于所有这些因素，我的建议是：
• 创建两项功能：一项用于原始标记，一项用于进行更改。 （或者您可以将它们放在同一个功能中；我只是想区分您在哪里做什么。）
• 原始功能应包含网站栏和内容类型的 CAML。这可确保 ID 在类型之前分配并保持不变。
• 如果您想要通过更改除字段类型之外的几乎所有内容来更新网站栏，请使用功能接收器来执行此操作。 无法通过 CAML 执行的操作）。
通过执行此操作，您可以调用 Update 方法并传入一个布尔值，指示您是否希望站点中从该方法继承的所有现有资产更新为（这是您 将现有网站栏（通过 CAML 功能配置）添加到现有内容类型（通过 CAML 功能配置）。如果列以前不是该内容类型的一部分，这会很有帮助。
• 在像我刚刚在最后一个要点中提到的场景中，有必要在之前停用并响应 CAML 功能（以配置新资产）呼叫您的功能接收器。这对网站意味着什么？由于网站列表中的所有网站栏和内容类型都使用与网站集根中配置的相同的 ID，因此从网站集中删除其父级不会改变这一点。它可能会使其暂时处于孤立状态（即该项目与网站集根中的项目之间不会有任何关系，但它将像往常一样发挥作用，因为它实际上是原始项目的功能齐全的副本）直到您重新激活将项目放回网站集的功能。就像当您停用该功能时父母正在度假，而当您再次激活该功能时父母正在回家一样。
您可以选择如何维护 CAML 和功能接收器，因为您有两种情况：现有网站集和新网站集。
• 您可以制定一项策略，每次在功能接收器中编写代码以更新网站栏或内容类型时，您也必须在 CAML 中进行更改。这意味着每次您在“新”网站集中激活 CAML 功能时，CAML 都会是最新且准确的；无需运行“更新程序”功能。 （在您的功能接收器中，您应该确保进行一些额外的检查，以确保网站栏在添加之前不属于内容类型，等等，以防在代码执行之前更改已经到位。）这种方法意味着您在创建新网站集时只需执行一项功能，但这也意味着您要在两个位置维护更改：在功能接收器中用于对现有网站进行更改，在 CAML 中用于新网站。这是一种更简洁的方法，但也包含冗余元素，总是为人为错误留下空间。
• 另一种方法是简单地假设每次基本 CAML 功能被激活时，您总是要执行功能接收器。这种方法表明，您更改 CAML 的唯一时间是添加新的网站栏或新的内容类型；否则，所有更改都发生在功能接收器中。这种方法减少了冗余，但也意味着随着时间的推移，您的功能接收器代码可能会随着您的所有更改而变得相当大，并且随着时间的推移，它可能会让您的 CAML 变得非常“遗留”。
源： http:// /blog.beckybertram.com/Lists/Posts/Post.aspx?List=eb3e1762%2Dbab0%2D4e96%2D8bc5%2Dd67d6e6bfd44&ID=18
Recommended Approach
Based on all these factors, my suggestion would be to:
• Create two Features: one for the original markup and one for making changes. (Or you can put them in the same Feature; I just want to differentiate between where you do what.)
• The original Feature should contain the CAML for Site Columns and Content Types. This ensures the IDs have been assigned ahead of type and remain constant.
• If you want to update a Site Column by changing nearly anything about it except its Field type, do it using a Feature Receiver. By doing this, you can call the Update method and pass in a boolean indicating if you want all the existing assets in the site that inherit from this to update to, (something you couldn't do via the CAML.)
• You can also add an existing Site Column (that you provisioned via the CAML feature) to an existing Content Type (that was provisioned via the CAML feature). This is helpful if the Column was not part of that Content Type before, etc.
• In a scenario like the one I just mentioned in the last bullet point, it's necessary to deactivate and reactive the CAML feature (to provision the new assets) before calling your Feature Receiver. What will this mean for the site? Since all the Site Columns and Content Types in the lists in the site are using the same ID's as the ones provisioned in the Site Collection root, removing its parent from the Site Collection won't change that. It might leave it orphaned temporarily, (i.e. there will be no relationship between that item and an item in the Site Collection root, but it will function the same way it always has, since it's really a fully-functioning copy of the original item) until you reactivate the Feature that puts the item back in the Site Collection. It's like the parents are going on vacation when you deactivate the Feature, and are coming back home when you activate the Feature again.
You have a choice when it comes to how you maintain the CAML and the Feature Receiver, since you have two scenarios: existing Site Collections and new ones.
• You could make a policy that every time you write code in your Feature Receiver to update a Site Column or Content Type, you have to make the change in your CAML as well. That would mean that every time you activated the CAML Feature in a "fresh" Site Collection, the CAML would be up-to-date and accurate; there would be no need to run the "updater" feature. (In your Feature Receiver, you should make sure you do some extra checking to make sure a Site Column doesn't already belong to a Content Type before adding it, etc. in case that change is already in place before the code executes.) This approach means you only have to execute one Feature when creating a new Site Collection, but it also means you're maintaining changes in two places: in your Feature Receiver for making changes to existing sites, and in your CAML for new sites. It's a cleaner approach, but also contains an element of redundancy, which always leaves room for human error.
• The other approach is to simply assume that every time the base CAML feature is activated, you're always going to execute the Feature Receiver. This approach says the only time you'd change the CAML is to add a new Site Column or new Content Type; otherwise, all the changes happen in the Feature Receiver. This approach reduces redundancy, but also means your Feature Receiver code could get quite large with all your changes over time, and it could leave your CAML as very much "legacy" over time.
Src: http://blog.beckybertram.com/Lists/Posts/Post.aspx?List=eb3e1762%2Dbab0%2D4e96%2D8bc5%2Dd67d6e6bfd44&ID=18
更新内容类型仍然是 Sharepoint 中尚未开发的部分之一，有时会引起麻烦，尤其是在内容部署场景中。
对于您的情况，最好的办法是始终避免手动（使用 UI）对内容类型进行任何更改。
每当您安装内容类型时，请确保删除前一个内容类型，然后安装新的内容类型。 （有时这是不可能的，因为页面已经用它创建了）。
Updating Content Types is still one of the underdeveloped portions of Sharepoint which sometimes causes trouble, especially in Content Deployment scenarios.
The best thing in your case would be to always avoid making any changes to content types by hand (using UI)
Whenever you are installing the content type, make sure that you remove the previous one and then install the new one. (Sometimes its not possible due to pages being already created out of it).
我当前部署内容类型的方法是尽可能使用代码而不是 CAML。这样就可以轻松地完全控制更新逻辑，包括确保手动所做的更改不会导致冲突。我将结构定义为接口上的属性，我也将其用于强类型列表访问，但还有其他几种方法可以做到这一点。
API 中唯一不可用的部分是设置特定的内容类型 ID，因此您需要为此拥有一个 caml 文件，但它是一个小/简单的文件，不会尝试进行更新，并且仅从还将运行更新代码的功能。
My current approach to deploying content types is to do as much as possible using code rather than CAML. That way it is easy to fully control the logic of updates, including ensuring that changes made manually don't cause conflicts. I have the structure defined as attributes on an interface I also use for strongly typed list access, but there are several other ways you could do it.
The only piece that isn't available in the API is setting a specific content type ID, so you need to have a caml file for that, but it's a small/simple file, doesn't try to make updates and is only referenced from a feature that will also run the update code.