C# 在.NET中创建COM组件以覆盖IE功能（自定义下载管理器）

我必须创建一个自定义下载管理器，它将取代Internet Explorer中的标准下载管理器。在谷歌搜索之后，我了解到我必须创建一个COM组件来实现

IDownloadManager

接口

据我所知，我必须创建一个dll，为它生成guid，并使用regasm.exe实用程序注册它，然后在windows注册表中为IE添加特定项。 我有几个问题：

我希望我的程序是一个exe，我希望能够手动运行它，并添加url到它，以及通过IE运行后，点击一个可下载的链接

虽然我更希望有一个可执行文件，但我认为要实现这一点，我必须创建dll和exe，并从dll中检查exe是否正在运行（按窗口id），如果没有运行，则运行，并以某种方式与之通信。这是正确的方法吗

我想与其他用户共享我的程序，我不想让他们手动注册COM。可以从代码中执行吗？或者我应该创建一个安装程序（我希望避免）

---

我将从一个警告开始：不要创建将加载到IE中的.Net组件。问问自己“如果另一个应用程序执行相同的操作，并且它使用不同版本的CLR，会发生什么？”。IE不保证加载所需的不同COM组件的顺序，因此也不保证在IE调用您时，您的CLR版本会在加载过程中加载

现在谈谈你的问题。您的场景有几个问题：

• .Net不支持本机创建进程外COM组件。是的，有可能创建一个通过做一堆黑客和手动注册；然而，这不是一项简单的任务，需要对COM如何工作有深入的了解
• 考虑到以上内容，您的选项实际上是创建一个.Net DLL，并使用ComVisible属性公开需要访问COM的类。正如您所提到的，您需要使用

  RegAsm.exe

  注册它，IE才能使用它
• 由于您希望下载管理器的主要功能位于独立的可执行文件中，因此必须使用.Net支持的跨进程通信机制。Net远程处理可能是实现它的最简单的方法，并且应该在很大程度上满足您的需求。另一种方法是在proc中实现下载功能。然而，除了考虑到你现在可以很容易地处理IE进程之外，如果你不仔细听它的退出通知（这本身需要更多的工作），还有整个带有IE7+保护模式的enchilada，这严重限制了你的in-proc代码的功能（有限的文件访问、注册表访问、Windows API和其他限制）
• IE8和IE9流程模型会带来一些复杂问题。除了顶层框架流程外，IE8/9还创建了一个流程池，并将选项卡负载平衡到这些流程中。我不知道哪个流程将尝试创建COM组件，以及是每个选项卡还是每个流程，还是整个IE会话（跨多个进程），因此您必须做好准备，使多个进程中可能有多个实例同时运行。如果是这种情况，您必须找出如何确保进程内COM组件和可执行文件之间的通信不会一次序列化一个实例，否则可能会影响用户的浏览体验（一个简单的场景是有多个下载链接的页面，用户右键单击每个链接并选择

  在新选项卡中打开

  ，从而一次在多个选项卡中启动多个下载）
• 即使每个IE会话有一个实例，出于安全原因，提升的IE实例也会在一个与普通用户IE实例不同的会话中运行。有一个有趣的复杂情况是，在提升的IE会话中，来自in-proc COM组件的.Net远程调用也会导致启动可执行文件的第二个副本因此，您的下载管理器必须准备好，可能有两个进程访问同一下载队列
• 从IE7开始，IE保护模式（默认）将截获任何导致启动新进程的调用并向用户显示对话框。避免这种情况的唯一方法是为您的进程注册静默IE提升策略。提升策略在

  HKEY_LOCAL_MACHINE

  中注册，这意味着您需要安装程序，或至少为用户注册一个简单的脚本s以管理员身份运行
• 即使您决定不使用提升策略，并忍受此对话框带来的糟糕体验，要在IE中注册下载管理器，您仍然必须向HKEY_LOCAL_机器注册表配置单元写入，否则IE将不知道它，也不会使用它。换句话说，您仍然需要某种安装程序或部署脚本；
• IE在衡量在UI线程上运行的代码的性能以及在退出进程时终止后台线程方面是相当积极的。因此，无论您在in-proc组件中拥有什么功能，您都必须在UI线程上尽可能快的速度之间取得平衡（这意味着更少的工作，否则会影响用户体验）和在后台线程上工作（这意味着做好准备，您可能会在没有通知的情况下随时被杀）

我认为这个列表涵盖了您必须解决的主要问题。您将遇到的最大问题是，关于IE流程模型的许多细节在MSDN上没有很好的文档记录，并且几乎没有在托管代码中实现此场景的示例（其中大多数都是旧的，没有针对IE8/IE9进行更新，有些甚至无法在IE7中工作）。

我将从