我正在维护一个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中进行内部编译),并显示“找不到项目或库”消息。
进一步更新:
我对最后一个假设进行了测试,结果证明是错误的。项目必须编译时组件必须实际存在。甚至不能是虚拟的或零长度的文件!现在我甚至不确定清单是否有效。这是一个更耗时的测试(需要具有产生不同结果的两个版本的组件,一个用于项目,另一个用于清单)。