我们有一个托管的 .Net COM+ 组件，它继承自 ServicedComponent，并尝试将其用作 Windows Server 2003 上 IIS 6.0 中 Web 应用程序的并行程序集。
我们已生成一个程序集使用 mt.exe 清单并已在测试控制台应用程序中以并行模式成功运行它。然而，当涉及到 IIS 时，它似乎不起作用，而是不再读取清单，而是从注册表中尝试查找 COM+ 应用程序。
清单是使用生成的
然后将 mt.exe -driven assemblyname:myassemble.dll -out:myassemble.manifest 复制到 Web 应用程序的虚拟目录。使用 filemon 显示清单从未被读取！
将 .manifest 文件移动到 bin 目录，然后它似乎被读取，但出现了同样的问题。
任何成功完成这项工作的人的帮助将不胜感激。
We have a managed .Net COM+ component which inherits from ServicedComponent and are trying to use this as a side-by-side assembly from a web application in IIS 6.0 on Windows Server 2003.
We have generated an assembly manifest using mt.exe and have successfully run this in side-by-side mode in a test console application. However, when it comes to IIS it just doesn't seem to work and rather than reading the manifest goes off the registry to attempt to find the COM+ application there.
The manifest is generated using
mt.exe -managedassemblyname:myassembly.dll -out:myassembly.manifest which is then copied to the virtual directory of the web application. Using filemon reveals that the manifest is never even read!
Moving the .manifest file to the bin directory it then seems to be read but the same issue occurs.
Help from anyone who has successfully got this working would be greatly appreciated.
发布评论
评论（1）
仅自动选取以“.manifest”结尾的外部清单作为可执行文件。
因此，您必须将您的清单告知 IIS 或 Windows，否则没有人会费心去阅读它。
据推测，在您的控制台应用程序测试中，可执行文件的清单具有对 MyAssembly 的引用，或者直接包含相关信息。
现在，我对
ServicedComponent不太熟悉，所以我将笼统地谈谈。MyAssembly的所有软件，您可以先故意加载清单中的信息，将该信息激活到线程中，然后调用MyAssembly，然后停用。这是满足这种插件架构的最佳方式，因为您不会污染父进程，您只需在代码运行期间配置代码运行的线程。这种方法是通过调用激活上下文 API 来完成的，您可以在与 一体化代码框架
MyAssembly的所有代码（如果它由 IIS 自动调用）或者如果它是在太多地方被调用，并且上面建议的方法成本太高，您总是可以在这里尝试“hackaround”。获取 IIS6.0 工作进程可执行文件，如果有清单，则编辑其清单，如果没有，则添加一个新清单（不要忘记检查它是否有嵌入式清单），以依赖于
MyAssembly< /代码>。在这种方法中，MyAssembly的清单内容本质上成为 IIS6 内运行的任何代码的运行上下文的一部分，因此这是一种相当重量级的方法。External manifests ending in ".manifest" are only automatically picked up for executables.
So you have to tell IIS or Windows about your manifest, or no one's going to bother to read it.
Presumably in your console application testing, either the executable's manifest has a reference to
MyAssemblyor contained the relevant information directly.Now, I'm not greatly familiar with
ServicedComponenthere, so I'm going to talk in general terms.MyAssembly, you can deliberately load up the information in the manifest first, activate that information onto the thread, call intoMyAssembly, and deactivate. This is the best way to satisfy this kind of plugin architecture, because you're not polluting the parent process, you're only configuring the thread your code is running on for the duration your code is running.This approach is done through invocation of the activation context APIs, of which you can find some great examples in the reg-free COM samples bundled with the All-in One Code Framework
MyAssembly(if it's being called automatically by IIS) or if it's being called in too many places and the approach suggested above is too costly, you could always try a "hackaround" here.Take the IIS6.0 worker process executable, and edit its manifest if it has one, or add a new manifest if not (don't forget to check if it has an embedded manifest), to have a dependency on
MyAssembly. In this approach,MyAssembly's manifest content essentially becomes part of the running context for any code running inside IIS6, so it's a pretty heavyweight approach.