SharePoint 的 OWSTIMER 服务保留对功能接收器程序集的引用答案

【问题标题】：SharePoint's OWSTIMER service keeping references to feature receiver assembliesSharePoint 的 OWSTIMER 服务保留对功能接收器程序集的引用
【发布时间】：2011-02-18 23:37:00
【问题描述】：

使用 SharePoint，您可以使用 Feature Receiver 在安装/卸载功能等时执行一些操作。

特征接收器是从OWSTIMER服务中运行的，过程似乎大致

.wsp（一个 cab 文件）被解压并检查
.dll 被移动到 bin/gac
清单中标记的功能接收器由服务调用（只能在 GAC 中）

但是，OWSTIMER 在包含功能接收器的 dll 上保持一个句柄打开。

这意味着当您卸载该功能时，Fusion 会将 dll 移动到 c:\windows\temp\ 目录并仍然保留引用。（更多详情here和here）

当您尝试安装新版本时（程序集文件版本不同但程序集版本必须保持不变）OWSTIMER 将运行旧功能接收器。

您可以通过重新启动 OWSTIMER 服务来阻止这种情况的发生，但这在可能有许多 Web 服务器的生产场环境中是不切实际的。

有人知道任何解决方法吗？

【问题讨论】：

标签： .net sharepoint gac fusion

【解决方案1】：

在交换功能之间执行 iisreset。

是的，会关闭所有网络应用程序，但这就是您计划中断/在几个小时内执行此操作的原因。并确保该过程在您的开发机器上进行了充分的演练。

【讨论】：

IISRESET 不起作用，因为该过程由 OWSTIMER 而不是 w3pwp 托管-您可以执行 net stop ... / net start ... 但正如解释的那样，这将是生产中的 PITA农场 - 不完全是一个简单的部署模型，并且嘲弄了从一台服务器运行 STSADM 操作以控制整个农场的想法。
好点 - 在我的想法中完全错过了 :) 看看这个，你可能需要开发扩展：sharepoint.mindsharpblogs.com/Paul/archive/2008/09/12/…
话虽如此 - 我最近一直在测试一个功能中的程序集卡在 GAC 中的问题（在 2007 年反复测试升级方案 [痛苦！[）- 每次IISRESET 修复了它 - 但就像你说的 - 它应该没有效果：|

【解决方案2】：

没有变通方法，但在您有许多服务器的生产环境中，您不应该从 GAC 手动 GAC-ing 和 un-GAC-ing DLL。

如果您通过功能架构进行部署，SharePoint 将自动处理此问题。

也就是说，如果您需要在场中的多个服务器之间同步 Windows 服务（包括 OWSTIMER 和 IIS）的启动/停止，只需编写一个批处理脚本即可使用：

SC \\SERVER1 STOP W3SVC
SC \\SERVER1 STOP SPTIMERV4
SC \\SERVER2 STOP W3SVC
SC \\SERVER2 STOP SPTIMERV4

然后使用以下命令重新启动：

SC \\SERVER1 START SPTIMERV4
SC \\SERVER1 START W3SVC
SC \\SERVER2 START SPTIMERV4
SC \\SERVER2 START W3SVC

【讨论】：

我没有手动 GAC-ing 和 un-GAC'ing dll - 一切都通过正常的功能架构和 SharePoint（2007 年和 2010 年，我假设 2013 年）不会自动处理这个- 这已得到 MS 开发人员支持的确认。