如何使 32 位 VB6 应用程序适应 64 位 Office？
我有一个使用 VB 6.0 和 VBA 开发的应用程序，使用最新的 Office 32 位版本。但由于此应用程序是 32 位，因此它无法在安装 64 位 Office 版本的系统上运行。将此应用程序移植到 64 位的最佳策略是什么？我们的任务是使用 VB.NET 并尽可能减少（尽可能）从 VB/VBA 到 .NET 64 位的代码修改。请建议我可以使用的最佳选项，以便我可以利用此移植的所有最佳实践。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
@Prof.Falken 的答案很好，移植到 VB.NET 本身可能是一个好主意，但这并不能保证您轻松获得应用程序的 64 位版本。如果您的 .NET 端口将使用 32 位 ActiveX 组件，而您没有 64 位替代组件，那么这将无济于事。以下列出了一些需要考虑的主题：
http://office.microsoft.com/en-us/word-help/choose-the-32-bit-or-64-bit-version-of-microsoft-office-HA010369476.aspx< /a>
在我们的工作场所，系统管理人员决定不在任何新的 64 位 Windows 计算机上安装 64 位 Office，因为这里使用的应用程序太多（也来自第三方供应商），否则会遇到麻烦。目前我们还没有看到 64 位 Office 版本给我们带来多少好处。
在这里我找到了另一个您可能感兴趣的链接：
http://www.pcpro.co.uk/news/enterprise/356173/microsoft-warns-users-off-64-bit-office-2010
The answer of @Prof.Falken is fine, and porting to VB.NET may be a good idea for itself, but this does not guarantee that you get easily a 64 bit version of your application. If your .NET port will use 32 bit ActiveX components for which you have no 64 bit replacement, then this won't help. Here are some topics listed to be considered:
http://office.microsoft.com/en-us/word-help/choose-the-32-bit-or-64-bit-version-of-microsoft-office-HA010369476.aspx
In our workplace, systems administration decided not to install 64 bit Office on any of the new 64 bit Windows machines since here are too much applications in use (also from third party vendors) which would run into trouble else. And currently we don't see much benefits for us from the 64 bit Office version nowadays.
Here I found another link which might be interesting for you:
http://www.pcpro.co.uk/news/enterprise/356173/microsoft-warns-users-off-64-bit-office-2010
根据代码的外观，其中一个或两个可能是一个好方法：
a) 将其移植到 VB.NET 或其他语言。
b) 将其保留在 VB6 中，但用包装器调用替换它与 Office 通信的每个位置。此包装器调用与 VB.NET 应用程序通信，而 VB.NET 应用程序又与 Office 通信。
方法b的结果是，它可以使旧的VB6程序中的所有业务逻辑保持不变。这是否合适取决于程序的外观、程序员的经验等等。旧的 VB6 程序和新的 VB.NET 可以通过 COM 或 XML-RPC 等相互通信。
Depending on what the code looks like, one or both of these may be a good way:
a) Port it to VB.NET, or another language altogether.
b) Keep it in VB6, but replace EVERY place it talks to Office, with a wrapper call. This wrapper call talks to a VB.NET application, which in turn talks to Office.
The upshot of method b, is that it makes is possible to keep all the business logic in the old VB6 program untouched. Whether this is suitable or not depends on what the program looks like, what the programmers are experienced with, and so on. The old VB6 program and the new VB.NET could talk to each other through for instance COM or XML-RPC.