我正在维护一个VB6应用程序，其中包含许多COM组件（DLL和OCX）。为了简化开发和部署流程，我想使用reg-free com。开发时的问题在于应用程序在VB6.EXE实例中运行。我该如何欺骗VB6使用我的（未注册的）组件？对我来说，不必在分支之间进行组件的注册/注销非常重要。生成VB6的.manifest文件并不是不可能的，但是否有其他更优选的方法可以指定在启动VB6.EXE时使用.manifest文件呢？
注意：即使在开发环境中使用Activation Context API也似乎没有帮助。
我想到的解决方案：
- 一个实用程序应用从.manifest激活上下文并启动VB6作为子进程（不起作用；进程不会继承激活上下文） - 在启动时将上下文激活注入到VB6进程中（过于复杂；必须修改可执行文件才能实现） - 在激活正确上下文后，在自己的进程中托管VB6（甚至无法确定是否可能） - 使用VB6插件或其他实用程序在VB6中运行以激活上下文（尝试过，但似乎不起作用）
注意：即使在开发环境中使用Activation Context API也似乎没有帮助。
我想到的解决方案：
- 一个实用程序应用从.manifest激活上下文并启动VB6作为子进程（不起作用；进程不会继承激活上下文） - 在启动时将上下文激活注入到VB6进程中（过于复杂；必须修改可执行文件才能实现） - 在激活正确上下文后，在自己的进程中托管VB6（甚至无法确定是否可能） - 使用VB6插件或其他实用程序在VB6中运行以激活上下文（尝试过，但似乎不起作用）
更新于1月16日
根据wqw的建议，我测试了VB.exe.manifest。VB6.exe.manifest有效，但有一些注意事项：
- 在没有实际引用组件的项目中，清单中指定的SxS dll不会出现在引用窗口中。
在引用了该组件的项目中，它将显示为位于以下顺序的目录中：
- 项目文件中记录的路径（如果文件仍然存在）
- 与项目（vbp）位于同一文件夹中的路径
如果文件不在这些文件夹中，则项目将无法编译（仅运行代码会在VB6中进行内部编译），并显示“找不到项目或库”消息。
进一步更新：
我对最后一个假设进行了测试，结果证明是错误的。项目必须编译时组件必须实际存在。甚至不能是虚拟的或零长度的文件！现在我甚至不确定清单是否有效。这是一个更耗时的测试（需要具有产生不同结果的两个版本的组件，一个用于项目，另一个用于清单）。