Question

我目前支持SharePoint“解决方案”，当我说“解决方案”时，我的意思是打包部署为.wsp文件的一系列功能（如Web部件，列表定义等）。这种方法称为developers approach，目前由于我们以MSI的形式提供此.wsp，升级过程要求用户撤回整个解决方案并重新部署。

在我通过提出新的升级方法来重新创建轮子之前，我想向SO SharePoint专家询问如何在保持sharepoint解决方案的同时缓解撤回解决方案和重新部署更新/补丁的繁琐过程的建议存储最新的dll。

最初的想法：

（1）创建一个powershell脚本，自动执行尽可能多的步骤，例如撤回旧解决方案，重新部署新解决方案，复制/更新配置文件。基本上重新部署解决方案。（目前使用的方法）
（2）将任何新补丁部署为新功能。
（3）您的想法/方法在这里。

Answer 1

我实际上并不使用.msi安装程序来部署SharePoint解决方案，主要是因为我觉得缩减，升级和重新部署解决方案比简单更新所需的侵入性更大。

stsadm SharePoint管理工具支持upgrading a SharePoint solution in-place。使用stsadm -o upgradesolution的吸引力在于您可以避免撤消，更新和重新部署代码。

另一方面，.msi安装程序的吸引力在于双击即可，不需要控制台安装解决方案。我尝试通过起草PowerShell脚本来处理所有stsadm命令等来弥补安装程序体验和原始stsadm体验之间的差距。

就地升级通常非常有效;但是，如果您计划对事件接收器类进行更改，则可能会发现需要完全停用 - 撤消 - 升级 - 部署 - 激活周期。

例如，我有一些WebApplication范围的功能，可以在激活该功能时向应用程序的web.config添加新的WebConfigModification条目。我是否应该添加新的web.config条目，在取消激活并重新激活该功能之前，新条目不会显示。

避免上述缺点的合理策略是在更改否则会强制停用 - 重新激活周期时实施新功能。

无论如何，解决方案部署策略只有两分钱。我希望它有所帮助。

Answer 2

我经常使用脚本打击使用stsadm命令来升级WSP包

这是带参数的命令：

stsadm -o upgradesolution -name "WSPName.wsp" -filename "c:/WSPName.wsp" -immediate -allowgacdeployment -allowcaspolicies

第二个命令用于强制立即执行此作业

stsadm -o execadmsvcjobs