我有一个 vb6 项目,由任意数量的不同开发人员(一些在 32 位 Windows 上,一些在 64 位 win 上)不时进行,但我们得到参考错误,因为一些引用的 Dll 位于(并已注册)程序中文件文件夹或程序文件(x86)文件夹,具体取决于机器,这似乎使 vb6 感到困惑。
查看 VBP 包含引用的路径,是否有设置引用以使其不会在任一系统上出错?
我有一个 vb6 项目,由任意数量的不同开发人员(一些在 32 位 Windows 上,一些在 64 位 win 上)不时进行,但我们得到参考错误,因为一些引用的 Dll 位于(并已注册)程序中文件文件夹或程序文件(x86)文件夹,具体取决于机器,这似乎使 vb6 感到困惑。
查看 VBP 包含引用的路径,是否有设置引用以使其不会在任一系统上出错?
据我所知(我可能是错的)VB6 实际上并没有将这些路径用于任何事情。相反,它使用 TypeLib GUID 和版本来查看注册表并找到包含类型信息的文件。然后它会更新路径,它仅在您再次保存 VBP 时使用。
也许只有在注册表中找不到类型库和版本时才会真正使用此路径。这可能会触发 VB6 尝试使用基于此路径的自注册入口点调用重新注册库。
如果这是不正确的,则以下内容不适用,尽管这通常是事情的运作方式:
您的问题似乎更有可能是 VB6 和/或这些(第 3 方?)库从未正确安装。
如果一个库没有全局注册(HKLM),那么每个打开此类项目的“新用户”(该机器上的新用户)都会根据 VBP 文件中的路径触发重新注册尝试。如果失败,他们将有一个损坏的参考问题。
如果 VB6.EXE 没有运行提升,则通过导航到库手动更正此问题会导致在注册表虚拟存储中为该用户重新注册库的副作用,从而使该用户的问题似乎消失。如果运行升高,那么它应该从那里开始为该机器上的每个人“解决”问题。这不是一个真正的治疗方法,因为您在各种用户的虚拟商店中注册了孤立的垃圾邮件,将来当图书馆更新时可能会咬到您。
VB6 和它将使用的库需要在完全提升时安装:它们的部分需要存储在非虚拟化文件夹中,并且组件必须在非虚拟化 HKLM 配置单元中注册。
VB6.EXE 应始终运行提升,并且如果通过应用应用程序清单来完成提升来完成此操作,则将是最可靠的,这会阻止旧应用程序虚拟化。
WOW64 注册表重定向是一个单独的主题。由于 VB6.EXE 是 32 位软件,应该透明运行。