在相关 DLL 中指定隔离 COM 设置还是仅指定可执行文件？
我正在 C++ VS2005 项目中设置隔离 COM 项目设置，以使用免注册激活方法加载 ocx 组件。如果 ocx 组件也在我的应用程序加载的 DLL 库中使用，我是否还需要在该 DLL 项目的设置中设置隔离 COM 设置？或者仅设置主应用程序的嵌入式清单就足够了？谢谢！
I'm setting the Isolated COM project settings in a C++ VS2005 project to load an ocx component using the Registration-Free Activation method. If the ocx component is also used in a DLL library my application loads, do I need to set the Isolated COM settings in that DLL project's settings as well? Or would setting only the main application's embedded manifest be sufficient? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
据我了解，隔离是针对每个进程的，而不是针对每个模块的。因此，应用程序清单中的任何内容都适用于从该应用程序启动的任何进程。
想想
CoCreateInstance需要做什么来支持免注册 COM —— 它需要以某种方式找到一个清单文件，如果存在的话，不会去注册表获取激活信息。由于
CoCreateInstance没有参数告诉它清单的路径，因此它需要从上下文中派生它。.DLL 没有真正的上下文，但对于 .EXE，当前进程句柄可用于派生可执行文件的路径等，因此我怀疑他们就是这样做的。
As I understand it, isolation is per-process, not per-module. So, anything in the application's manifest applies to any process started from that application.
Think of what
CoCreateInstanceneeds to do to support reg-free COM -- it needs to find a manifest file somehow and if it's present, not go to the registry for activation information.Since there is no argument to
CoCreateInstancetelling it the path of the manifest, it needs to derive it from context.There is no real context for a .DLL, but for an .EXE the current process handle can be used to derive the path of the executable, etc., so I suspect that's how they do it.