0

我们有一个托管的 .Net COM+ 组件，它继承自ServicedComponentWindows Server 2003 上的 IIS 6.0 中的 Web 应用程序，并试图将其用作并行程序集。

我们已经使用mt.exe并在测试控制台应用程序中以并行模式成功运行了程序集清单。但是，当涉及到 IIS 时，它似乎无法正常工作，而是从注册表中读取清单以尝试在那里找到 COM+ 应用程序。

使用清单生成清单 mt.exe -managedassemblyname:myassembly.dll -out:myassembly.manifest，然后将清单复制到 Web 应用程序的虚拟目录。使用filemon表明清单甚至从未被读取！

将.manifest文件移动到bin目录，然后似乎可以读取它，但会出现同样的问题。

任何成功完成这项工作的人的帮助将不胜感激。

4

1 回答 1

0

以“.manifest”结尾的外部清单只会自动获取可执行文件。所以你必须告诉 IIS 或 Windows 你的清单，否则没有人会费心去阅读它。

大概在您的控制台应用程序测试中，可执行文件的清单直接引用MyAssembly或包含相关信息。

现在，我对这里不是很熟悉ServicedComponent，所以我将笼统地说。

  1. 如果您可以控制所有调用 的软件MyAssembly，您可以先故意加载清单中的信息，将该信息激活到线程上，调用MyAssembly并停用。这是满足这种插件架构的最佳方式，因为您不会污染父进程，您只是在代码运行期间配置代码正在运行的线程。这种方法是通过调用激活上下文 API 来完成的，您可以在与All-in One Code Framework捆绑的无注册 COM 示例中找到一些很好的示例
  2. 如果您无法控制所有调用的代码MyAssembly（如果它被 IIS 自动调用），或者如果它在太多地方被调用并且上面建议的方法成本太高，那么您总是可以在这里尝试“hackaround”。获取 IIS6.0 工作进程可执行文件，如果有，则编辑其清单，如果没有，则添加新清单（不要忘记检查它是否具有嵌入式清单），以依赖MyAssembly. 在这种方法中，MyAssembly的清单内容本质上成为在 IIS6 内运行的任何代码的运行上下文的一部分，因此它是一种相当重量级的方法。
于 2011-01-10T09:55:03.967 回答