我有一个包含多个事件接收器和工作流的复杂共享点部署。

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

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

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

请告诉我这对任何 SharePoint 专家来说是否有意义。

谢谢你,
基思

更新:查看网站 德拉克斯 参考,我找到了这个参考网站: http://msdn.microsoft.com/en-us/library/aa543659.aspx

这种说法似乎给解决方案的功能升级带来了很大的障碍:

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

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

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

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

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

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

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

  • 在新版本的解决方案中删除功能元素(element.xml文件)。

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

所以...解决方案升级可以做什么?

有帮助吗?

解决方案

我会建议 反对 将所有事情分成多个解决方案。维护很快就会变成噩梦。尝试以与共享点的 12 文件夹相同的方式构建您的项目,该项目应该用于创建 WSP。然后你可以使用 水安全计划建设者, ,最后一个稳定版本带来了很多有用的东西。

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

编辑:

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

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

基本上,就地更新是标准的更新方式。这意味着您依赖于内置功能,如中所述 (与之前发布的文件相同)文件。该解决方案的问题在于它缺乏很多功能(版本控制、更改功能 ID 等)。

增量更新(这可能是微软的称呼)不依赖于内置解决方案。这意味着每个人都需要自己实现它:(。更好的是,我确实无法找到这种方法的任何指导方针。我想您想要采用的方法是增量更新的示例(将项目拆分为许多独立的解决方案)。

另请注意,MS 并未正式支持增量更新。

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

我可能会等待,看看具有更多 MOSS 专业知识的人是否可以就这个话题发表一些看法。

其他提示

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

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

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

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top