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

解决方案

回答

我已经完成了一些SharePoint开发，并且我必须告诉我们，如果我们想移动应用程序，那么搞砸12个配置单元是一个痛苦的世界。

我宁愿破解一些JavaScript来隐藏它，至少可以将其绑定到母版页上，而该母版页则更具可移植性。
记住，我们永远都不知道下一个Service Pack何时出现并破坏更改:)

回答

我同意拉斯。有时，我们将无法避免它，具体取决于需求。但是，通常最好的策略是尽可能避免修改。

我知道当前用户菜单中的其他一些菜单项(更改登录名，我的设置等)可以通过从用户删除权限来进行更改。在"用户和组"下，有一个权限选项。我不记得确切的设置(在工作中而不是在家中进行开发)，但是30多个权限中的每一个旁边都有合理的说明。删除它，我们开始隐藏菜单选项。无需修改12个配置单元。

回答

不确定是否有很多用途，因为其他人几乎都可以涉足，但我也要说不要这样做。尽管很诱人，但几乎不可能知道所做的微小更改的全部影响。

从支持的角度来看，我们将很难获得Microsoft支持(补丁/修补程序)。
从维护的角度来看，我们还需要承担长期成本。

转到javascript路线。

回答

解决方法是使用Sharepoint解决方案(WSP)文件。

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

在解决方案中包括此功能。

使用stsadm命令行或者通过Central Site Admin部署解决方案。

然后，它将自动部署到服务器场中的所有服务器，并且避免我们覆盖任何默认共享点文件。

有关更多信息，请访问http://www.sharepointnutsandbolts.com/上的Sharepoint螺母和螺栓博客，其中介绍了WSP和Sharepoint功能。

回答

我已经做过很多次了，我将根据经验发言：在任何情况下，切勿触摸12个配置单元中的onet.xml文件。我们在其中犯的任何错误以及使CAML更加复杂的文件在很大程度上都对空格敏感，这将对SharePoint的每个部分产生影响。

我们还应该考虑到，除了安装的巨大风险外，我们还很可能依赖于所做的更改，这些更改随后会在以后的补丁程序或者Service Pack中被覆盖。

回答

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

我从未遇到过唯一的解决方案就是更改此类文件的情况。例如，如果我们想更改SharePoint的即用型用户控件，则可以通过使用DelegateControl并将其覆盖在功能中来进行更改。

更多信息：

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

我知道快速更改文件很诱人，而且我不得不承认有时候我只是在DEV盒上这样做，但不要在生产服务器上去！

回答

大多数时候，我们可以使用功能和解决方案包来完成所需的所有工作，而无需修改文件。但是，在少数(相当烦人)罕见的情况下，我们唯一的选择是修改系统上的文件。到目前为止，我已经将它用于两个特定的情况。一种是将PDF iFilter添加到docicon.xml文件，另一种是将主题添加到themes.xml文件。在这两种情况下，这似乎都是实现目标的唯一途径。尽管如此，我们还是使用一个解决方案包将这些文件写到服务器场中的所有服务器上。