修改SharePoint系统文件

Question

开发人员对12个hive中文件更改的一般感受是什么？ 例如，如果要求您删除该标志是另一个用户菜单项，则需要修改文件系统上的相关用户控件。现在，如果您只是通过记事本进行修改或复制，然后如果您将新服务器带入服务器场，则需要记住在新服务器上执行相同操作。 显然，您可以将更改后的文件部署为解决方案并自动完成，但我只是想知道人们是否对更改默认安装文件犹豫不决？

Answer 1

我已经做了一些SharePoint开发，我必须告诉你，如果你想移动应用程序，弄乱12-hive是一个痛苦世界的门票。

我宁愿破解一些javascript来隐藏它，至少可以绑定到母版页，这样便于携带。
请记住，您永远不知道下一个服务包何时到来并且能够改变您的变化：）

Answer 2

我同意Lars的观点。有时根据您的需要，您将无法避免它。但是，一般来说，最好的政策是尽可能避免修改。

我知道当前用户菜单中的一些其他菜单项（更改登录，我的设置等）可以通过删除用户的权限来更改。在“用户和组”下，有一个权限选项。我不记得确切的设置（在工作中开发，而不是在家里开发），但在30多个权限的每一个旁边都有合理的描述。删除它，然后开始隐藏菜单选项。不需要修改12-hive。

Answer 3

有一个非常简单的规则：如果您想保留Microsoft的官方支持，请不要更改SharePoint安装的12个配置单元中的任何文件。

我从来没有遇到过唯一的解决方案是改变这样一个文件的情况。例如，如果要更改SharePoint的现成用户控件，可以通过使用DelegateControl并在功能中覆盖它来实现。

更多信息：

• http://msdn.microsoft.com/en-us/library/ms463169.aspx
• http://www.devx.com/enterprise/Article/36628

我知道快速更改文件很有吸引力，我不得不承认有时我只是在DEV盒子上这样做，但是不要去生产服务器上去！

Answer 4

不确定是否有太多使用投球，因为其他人几乎已经覆盖了，但我也会说不要这样做。虽然它很诱人，但却无法知道你所做的那一点改变的全部影响。

从支持角度来看，您将难以获得Microsoft支持（修补程序/修补程序）。 从维护的角度来看，您也可以为自己打开长期成本。

转到javascript路线。

Answer 5

实现它的方法是使用Sharepoint Solution（WSP）文件。

要更改用户控件，请使用新功能创建新的Sharepoint功能。

在您的解决方案中包含此功能。

使用stsadm命令行或通过中央站点管理员部署解决方案。

然后，它将自动部署到服务器场中的所有服务器，并避免您覆盖任何默认的sharepoint文件。

有关详细信息，请查看http://www.sharepointnutsandbolts.com/上的Sharepoint Nuts and Bolts博客，其中介绍了WSP和Sharepoint功能。

Answer 6

我已经多次这样做了，我将根据经验说话：在任何情况下都不要触摸12个hive中的onet.xml文件。您在那里犯的任何错误，以及使CAML更加复杂的文件在很大程度上都是空白敏感的，将对SharePoint的每个部分产生影响。

您还应该考虑到除了安装的实质性风险之外，您可能会依赖于您的更改，然后在未来的修补程序或Service Pack中覆盖这些更改。

Answer 7

大多数情况下，您可以在不修改文件的情况下完成使用功能和解决方案包的所有操作。但是，有一些（相当令人讨厌的）罕见情况，您唯一的选择是修改系统上的文件。到目前为止，我已经将它用于两个特殊情况。一种是将PDF iFilter添加到docicon.xml文件中，另一种是将主题添加到themes.xml文件中。在这两种情况下，它似乎是实现目标的唯一途径。尽管如此，我们仍然使用解决方案包将这些文件写入服务器场中的所有服务器。