MOSS Web 解决方案包在移动时损坏
我有 moss .wsp，它安装在单个共享点服务器上，并且在预览模式下可以正常工作。
我现在已将 SharePoint 网站移至另一台服务器并添加/部署了相同的 .wsp，但在这台新服务器上尝试预览库中的 Web 部件时出现以下错误：
预览 Web 部件时发生错误。 在 Microsoft.SharePoint.WebPartPages.WebPartPreview.CreateChildControls() 在 System.Web.UI.Control.EnsureChildControls() 在 System.Web.UI.Control.PreRenderRecursiveInternal() 在 System.Web.UI.Control.PreRenderRecursiveInternal() 在 System.Web.UI.Control.PreRenderRecursiveInternal() 在 System.Web.UI.Control.PreRenderRecursiveInternal() 在 System.Web.UI.Control.PreRenderRecursiveInternal() 在 System.Web.UI.Control.PreRenderRecursiveInternal() 在 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
任何人都可以建议如何找到可能导致问题的原因，同时记住这是一个生产环境？
一切顺利
I have moss .wsp that is installed on a single sharepoint server and works correctly when in preview mode.
I have now moved the SharePoint site to another server and added/deployed the same .wsp but on this new server I get the following error when trying to preview the web part in the gallery:
An error occured when previewing the Web Part. at Microsoft.SharePoint.WebPartPages.WebPartPreview.CreateChildControls()
at System.Web.UI.Control.EnsureChildControls()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
Can anyone suggest how to find what might be causing the problem bearing in mind that this is a production environment?
All the best
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否在测试环境中测试了您的包，或者只是将构建 WSP 从开发服务器复制到生产环境？
各种各样的事情都可能出错，因此很难从上面猜测发生了什么。
有根据的猜测是，您的包不包含开发环境中的所有相关工件（第三方 dll、用户控件，任您选择！）
因此，拥有一个测试环境被认为是一个很好的做法（通常比并非我们的客户有 5 个环境，所有环境都已编写脚本，因此我们可以确保它们尽可能相同），以便您可以在部署到生产之前测试您的包是否实际工作！
我还可以推荐开发环境的快照，以便您每周都可以刮擦您的开发服务器。 它们很快就会变得与测试和生产环境不同，这就是事情开始变得丑陋并且包在测试服务器上损坏的地方。
哈
安德斯·拉斯克
Did you test your package on a test environment, or just copy the build WSP from your dev server to production?
All sorts of things could have gone wrong, so it would be very hard to guess from the above what is happening.
An educated guess would be that your package did not contain all relevant artifacts that was there on your dev environment (third party dll, user control, take your pick!)
Hence it is considered a good practice to have a test environment (more often than not our customers have 5 environments, all scripted so we can be sure they are as identical as possible) so that you can test that your packages actually work before deploying to production!
Also i can recommend snapshots of dev environments, so that you can scratch your dev servers every week. They can all too quickly become different from the testing and production environment, and this is where things start to get ugly and packages break on test server.
hth
Anders Rask
如果您只是移动内容数据库，您可能需要重新部署 WSP。
WSP 在 SharePoint 配置单元内本地部署文件 (C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12)，并且很可能需要运行。
如果您没有将新服务器加入场，然后断开旧服务器的连接，则文件很可能会丢失。
If you simply moved the content database over, you might want to redeploy your WSP.
WSP deploy files locally inside the SharePoint hive (C:\Program Files\Common Files\Microsoft Shared\Web server extensions\12) and are most likely required to run.
If you didn't join a new server to the farm and then disconnected the old server, the files are most likely missing.
检查 12 个配置单元中的日志，有时它们包含有用的信息。
Check the logs in the 12 hive, sometimes they contain helpful information.