4

我有一个包含多个 EventReceiver 和工作流的复杂共享点部署。

我还对现有列表进行了架构更改，添加了新的元数据列并更改了现有列。

我应该将单个功能、事件接收器或工作流打包到单个解决方案中，还是应该将多个功能放在单个解决方案中，因为它们都可以协同工作？

我问的一个主要原因是未来的代码升级。如果功能是分开的，那么升级一部分代码将不需要重新部署解决方案中的所有功能。这是我应该担心的事情，还是“stsadmin -o upgradesolution”可以解决升级具有许多功能的解决方案的任何问题？

让我知道这对任何 SharePoint 专家是否有意义。

谢谢你，
基思

更新： 查看引用的网站drax，我发现了这个参考网站：http: //msdn.microsoft.com/en-us/library/aa543659.aspx

该声明似乎对解决方案中的升级功能造成了很大的障碍：

解决方案升级只能用于替换文件。您可以在解决方案升级中添加新文件并删除旧版本的文件，但您不能安装功能或使用功能事件处理程序来运行功能安装和激活代码。解决方案升级不支持以下操作。

  • 在新版本的解决方案中删除旧功能。

  • 在解决方案升级中添加新功能。

  • 在新版本的解决方案中更新或更改现有功能的接收器组件。

  • 在新版本的解决方案中添加或更改功能元素（Element.xml 文件）。

  • 在新版本的解决方案中添加或更改功能属性。

  • 在新版本的解决方案中更改旧功能的 ID 或范围。

  • 在新版本的解决方案中删除功能元素（Element.xml 文件）。

  • 在新版本的解决方案中删除功能属性。

那么...您可以通过解决方案升级做什么？

4

3 回答 3

1

我建议不要将所有内容拆分为多个解决方案。维护这很快就会变成噩梦。尝试以与 sharepoint 的 12 文件夹相同的方式构建您的项目，该项目应该用于创建 WSP。然后你可以使用WSP builder，最后的稳定版本带来了很多有用的东西。

我也没有注意到重新部署解决方案有任何问题。根据这篇文章和我的经验，WSP 的部署负责版本之间的同步。因此，如果您要添加一些新功能，它们将出现，如果您删除/更改功能，它们将被相应地修改。

编辑：

所以我对 MOSS 更新主题做了一些快速研究。根据 MS 的说法，有两种更新解决方案的方法：

  1. 就地更新
  2. 增量更新

基本上，就地更新是标准的更新方式。这意味着您依赖于本文档（与之前发布的相同文档）中描述的内置功能。这个解决方案的问题在于它缺少很多功能（版本控制、更改特性的 ID，......）。

增量更新（这可能是 MS 的称呼）不依赖于内置解决方案。这意味着每个人都可以自己实现它:(。更好的是我真的找不到这种方法的任何指导方针。我想你想采用的方法是增量更新的例子（将项目拆分为许多独立的解决方案）。

另请注意，MS 不正式支持增量更新。

所以我真的不知道我应该给你什么建议。单个 WSP 比它们中的大多数更易于维护，如果您只进行一些小的更改，更新也可以完美地工作。但是，如果您需要进行一些更大的结构性改变，问题就会开始显现。

我可能会拭目以待，看看是否有更多 MOSS 专业知识的人可以就这个话题发表意见。

于 2008-12-17T17:09:49.513 回答
0

基本上（出于您提到的原因），您应该像 .Net 程序集一样考虑解决方案 - 可以与其他代码分开部署的原子代码单元。使用 upgradesolution 将导致重新部署所有包含的功能 - 如果没有任何更改，那么使用该功能的站点应该没有任何更改。但是，如果这让您感到紧张，请考虑将其分开。

于 2008-12-17T16:03:18.573 回答
0

如果您只是更新程序集并保持配置文件完好无损，UpgradeSolution 非常方便。

除非您指定 -local，否则 upgradesolution 将在您的基础架构中执行完整的 iisreset。当您计划执行升级的正确时间时，这确实值得注意。

于 2009-10-22T08:35:36.147 回答