有没有办法强制 IE 卸载 ActiveX 控件？答案

【问题标题】：Is there a way to force IE to unload an ActiveX control?有没有办法强制 IE 卸载 ActiveX 控件？
【发布时间】：2010-10-11 15:02:44
【问题描述】：

我们有一些动态 HTML 页面，其中包含一个实例化 ActiveX 控件的<OBJECT> 标记。然后用户可以导航到另一个页面，该页面包含一个指向更新版本的 ActiveX 控件的<OBJECT> 标记。

IE 将在第二页下载并安装新的 ActiveX，这就是该页面的用途。问题是，由于 IE 在第一页加载了 ActiveX，它现在将强制用户在完全安装下载的 ActiveX 之前重新启动，因为它正在被进程 (IE) 使用。

在普通容器中，我会在尝试升级之前简单地卸载 ActiveX。有没有办法强制 IE 这样做？如果这样做可以解决问题，那么浏览不使用控件的页面是可以接受的。

编辑：

要求 ActiveX 本身做某事的解决方案不会起作用，因为问题是当 IE 开始安装新版本的 ActiveX 时 ActiveX 仍在内存中。我要做的是在 IE 启动该进程时不在内存中拥有 ActiveX，因此显然我不能依赖 ActiveX 控件本身中的任何内容。

【问题讨论】：

Ori，这是一个非常好的问题。是您自己的 active-x 控件，即您可以更改它，还是您只有二进制形式？

标签： internet-explorer com activex

【解决方案1】：

试试javascript删除语句：

function unloadObject(objId) {

    var obj = document.getElementById(objId);

    obj.parentNode.removeChild(obj);

    delete obj;
}

在打开您的第二页之前，请致电unloadObject(targetActiveXTagId)。

理想情况下，您应该将升级机制构建到您的 ActiveX 本身中。我见过几个在线游戏平台这样做的效果很好。

【讨论】：

【解决方案2】：

虽然我不知道如何让 IE 卸载 DLL（它使 DLL 文件句柄保持打开状态——我希望它能正确释放对象本身...）我使用的一种解决方案是将 DLL 复制到到一个临时文件（基于程序集版本），然后再打开它，然后显式破坏 IE/COM/whatever 缓存。因此，即使旧的 DLL 文件句柄保持打开状态，我也可以加载“新”版本。

只有当所有这些都满足时，我才能够打破缓存：

不同的 ProgID（动态生成，可能与 DLL 不同）
不同的 CLSID（也是动态生成的——就像一个魅力）
不同的 DLL 名称（通过制作原始文件的副本并使用程序集版本可以避免 DLL-in-use-access 错误）
不同的程序集版本（这是用于 .NET）

我正在开发侧边栏小工具，因此我可以只使用一些特权 ActiveX 脚本友好组件来完成上述工作，但预加载器（未更新）ActiveX 组件也可以完成这项工作。

我依靠 .NET/mscoree.dll 来处理 COM 的东西，所以可能会有一个更清洁的方法进入较低级别。

不同的“版本控制”通过暂时加载到 HKCU\Software\Classes 结构中来处理。

【讨论】：

【解决方案3】：

我认为这是不可能的。

【讨论】：

【解决方案4】：

您可以尝试的一件事是让安装程序调用 CoFreeUnusedLibraries()，然后在 ActiveX 控件中的 DllCanUnloadNow() 中使用 S_OK 响应。这可能会让你卸载，但我想知道 IE 是否仍会尝试回调到你卸载的模块。简单到可以尝试。

您也可以只编写一个存根 DLL 来实现您拥有的触摸 IE 的所有接口，然后只需 thunk 到实际实现该功能的 real DLL。然后你可以让你的安装程序广播一条消息，上面写着“卸载真正的 DLL”。然后，您在完成后广播另一条消息并加载新消息。在进行更新时，您的存根会显示“请稍候，我正在更新...”消息。

【讨论】：

但是您的超级问题的答案是，不，IE 不会为您提供强制卸载任何扩展的方法。这很烦人。
什么安装程序？ IE 下载 cab 文件（由 OBJECT 标记中的 CODEBASE 属性指向）并注册它。除了 .ocx 文件中的一些自我注册代码之外，没有涉及安装程序代码，但是当它被加载时，为时已晚。
你应该可以在 cab 文件中指定一个 .exe 文件首先运行，除非他们加强了安全性。
嗯...我在文档中找不到那个位。

【解决方案5】：

您是否尝试过使用 Javascript 来杀死 ActiveX 控件所在的 DOM 元素？如果你这样做，IE 会告诉控件卸载，但你必须确保控件实际上会卸载。然后，您应该能够使用较新的对象引用点击页面，这将启动较新的对象....

如果做不到这一点，您可以尝试打开一个弹出窗口，将您定向到一个从不加载您的对象的页面，同时，使用对主浏览器的命名引用，将其重定向到一个不引用您的页面的页面对象，让它有机会卸载，然后重新引用更新的 ActiveX。这应该会加载您的新控件。

无论你走哪条路，这都是一个棘手的问题，但你也许可以让它做你想做的事。

如果您的控件行为不正常，它可能无法正确卸载，因此您必须注意这一点。

拉里

【讨论】：

【解决方案6】：

你不能改变工作流程吗？先检查更新，避免整个问题！

无论您实施何种解决方案，浏览器均由客户端控制，任何（安全）更新或新版本都可能破坏您的系统。

【讨论】：

这不是一个真正的选择。问题是一些客户使用过时版本的 ActiveX（由于严格的 IT 政策），并且在一些配置错误的机器上，IE 尝试下载新的 ActiveX，尽管没有足够的权限来安装它，所以应用程序...
为这些用户提供不同版本的 ActiveX，但 ActiveX 也出现在登录页面上，但那是过时的版本。有一种解决方法，但并不理想。我仍然对我的问题的答案感兴趣。

【解决方案7】：

愚蠢的回答，对不起。如果您仍然有这个问题，我猜重定向不起作用。如果您没有尝试，只需创建一个重定向到您更新的 ActiveX 页面并链接到那里的页面。

middleman.html:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>blank page</title>
<meta http-equiv="REFRESH" content="0;url=http://www.newactivexcontrol.com"></HEAD>
<BODY>
</BODY>
</HTML>

【讨论】：

对不起，我只是不明白这与问题有什么关系。

【解决方案8】：

显然是和不是。

这可能发生，但前提是您通过安全漏洞“破解”它。所以不是通过任何合法程序，不。

这是一篇描述漏洞状态的文章： http://www.juniper.net/security/auto/vulnerabilities/vuln16409.html

这里有一篇关于 Technet 的文章，讨论了 DWORD ActiveX 如何杀死进程 http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q240797&sd=tech

这是来自 MSDN 网站关于 ActiveX 控件的引用：

“用户不能直接与由 APPLET、EMBED 或 OBJECT 元素加载的 Microsoft ActiveX 控件进行交互。用户可以在激活其用户界面后与此类控件进行交互。” http://msdn.microsoft.com/en-us/library/ms537508.aspx

【讨论】：

对不起，这与问题并不完全相关，尽管这本身就是一个有趣的话题。
Killbits 与他的问题无关。