我有几个正在部署到生产环境的自定义 Web 部件。在这个过程中，我发现了一些需要在各个部分进行调整的小事情。为了部署新代码，我创建了一个新的解决方案包，停用然后删除功能，收回然后删除解决方案，然后使用新包以相反的顺序再次执行所有操作。不用说，这可能很耗时。是否需要完全删除 Web 部件才能对其进行升级，或者是否可以就地升级 Web 部件/功能/解决方案？
问问题
1243 次
4 回答
2
这取决于您的解决方案中究竟发生了什么变化。有一个专门用于升级解决方案的 stsadm 操作，但它在处理的内容方面存在一些限制，最明显的是删除旧功能和添加新功能。但是，如果您的所有新功能都存在于 Webpart DLL 中，则运行解决方案升级将部署您的更改，而无需您进一步执行任何操作。
于 2009-08-04T21:29:37.063 回答
0
我们使用了适用于 Windows SharePoint Services 3.0、v1.3 - 2009 年 3 月 CTP 的 Visual Studio 2008 扩展。它给我们带来了一些问题，但是当你习惯它并确保你以正确的顺序做事时，它就会起作用。
该工具可自动执行 retact / delete / deploy / activate .... 作业。
我们尝试做的另一件事是在 Web 部件中保留尽可能少的功能。将可以移动的内容移动到单独的 dll 中，然后通常可以通过处理新版本的 dll 来进行升级。
于 2009-08-04T18:35:48.567 回答
0
如果您对 Web 部件进行细微更改，则只要程序集版本保持不变，您就可以替换DLL。
当然，对于什么是小改动并且不会破坏任何东西，请在此处使用一些判断力。
有关如何正确使用 FileVersion 和 AssemblyVersion的信息，请参阅本主题。
基本上，您保持 AssemblyVersion 相同以进行较小的更新，而 FileVersion 会随着编译而改变。
这正是微软使用 Microsoft.SharePoint.dll 之类的东西的方式——AssemblyVersion 固定为 12.0。？？？而 FileVersion 随每个修补程序/服务包而变化。
哦-我刚刚阅读了您答案的“生产部分”，此快捷方式可能更适合开发/测试而不是 QA/生产
于 2009-08-05T11:13:24.173 回答
0
用这个
stsadm -o upgradesolution -name "WSPName.wsp" -filename "c:/WSPName.wsp" -immediate -allowgacdeployment -allowcaspolicies
然后运行共享点作业
stsadm -o execadmsvcjobs
另一方面，您可以使用 SharePoint PowerShell 命令更新 dll
Set-location "C:\Users\Documents\WSP"
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\Users\Documents\WSP\wspcustom.dll")
于 2015-09-17T12:52:11.927 回答