我有一个复杂的sharepoint部署，有多个EventReceivers和Workflows。
我还对现有列表进行了架构更改，添加了新的元数据列并更改了现有列。
我应该将单个功能，事件接收器或工作流程打包到单个解决方案中，还是应该将多个功能放在单个解决方案中，因为它们一起工作？
我要问的一个主要原因是未来的代码升级。如果功能是分开的，那么代码的一部分升级将不需要重新部署解决方案中的所有功能。这是我应该担心的事情，还是“stsadmin -o升级解决方案”会解决升级具有许多功能的解决方案的任何问题？
如果这对任何SharePoint专家都有意义，请告诉我。
谢谢你，
基思
更新 查看引用的网站drax，我找到了此参考网站：http://msdn.microsoft.com/en-us/library/aa543659.aspx
这句话似乎对升级解决方案中的功能造成了很大的障碍：
解决方案升级只能用于 替换文件。您可以添加新文件 在解决方案升级和删除旧 文件的版本，但你不能 安装功能或使用功能事件 处理程序以运行Feature的代码 安装和激活。该 不支持以下操作 在解决方案升级中。
删除新功能中的旧功能 解决方案的版本。
在解决方案中添加新功能 升级。
更新或更改接收器 装配现有功能 新版本的解决方案。
添加或更改要素元素 （Element.xml文件）在新版本中 解决方案。
添加或更改功能 新版本中的属性 溶液
更改旧ID或范围 新版本的功能 溶液
删除要素元素 （Element.xml文件）在新版本中 解决方案。
删除新功能 解决方案的版本。
那么......解决方案升级可以做些什么？
答案 0 :(得分：1)
我建议反对将所有内容分成多个解决方案。维持这可能很快成为噩梦。尝试构建您的项目，该项目应该用于创建WSP，方式与sharepoint的12个文件夹相同。然后你可以使用WSP builder，最后一个稳定版带来了很多有用的东西。
此外，我没有发现重新部署解决方案有任何问题。根据{{3}}文章和我的经验，WSP的部署负责版本之间的同步。因此，如果您要添加一些新功能，它们将会显示，如果您删除/更改功能，它们将相应地进行修改。
编辑：
所以我对MOSS更新主题进行了一些快速研究。根据MS，有两种更新解决方案的方法：
基本上，就地更新是标准的更新方式。这意味着您依赖于this（与之前发布的文档相同）文档中所述的内置功能。这个解决方案的问题在于它缺乏相当多的功能（版本控制，更改ID的功能......）。
增量更新（这可能是MS调用它的方式）不依赖于内置解决方案。这意味着每个人都应该自己实现它:(。什么是更好的我真的无法找到这种方法的任何指导。我想你想采取的方法是增量更新的例子（将项目拆分为许多独立的解决方案）。
另请注意，MS不正式支持增量更新。
所以我真的不知道我应该给你什么建议。单个WSP比它们更加可维护，如果你只做一些小的更改更新工作完美。但是如果你需要做一些更大的结构变化问题就会开始显示出来。
我可能会等等，看看拥有更多MOSS专业知识的人是否可以就此话题说些什么。
答案 1 :(得分：0)
基本上（出于你提到的原因），你应该像解决方案一样考虑解决方案.Net程序集 - 可以与其他程序分开部署的原子代码单元。使用升级解决方案将导致重新部署所有包含的功能 - 如果没有任何更改，则对于使用该功能的站点，不应更改任何内容。但是，如果这让你感到紧张，可以考虑把它分开。
答案 2 :(得分：0)
如果您只是更新程序集并保留配置文件，则UpgradeSolution非常方便。
除非您指定-local，否则升级解决方案将在您的基础架构中执行完整的iisreset。当您计划进行升级时，这非常值得注意。