Windows Azure 上的 32 位旧版 COM DLL

Question

我在我的 Web 应用程序中使用了大约 15-20 个旧版 32 位 C++ COM DLL，其中一些 32 位 DLL 具有第三方依赖项，它们是 DLL 的 COM 或本机。

我正在考虑迁移到 Windows Azure，据我所知，它是一个 64 位平台。谁能建议我的 32 位 DLL 是否可以工作？ （我知道现在可以对它们进行 regsvr32 了）。

经过一两个星期的工作，我可以将我的 DLL 重新编译为 64 位，但是这对于 3rd 方依赖项是不可能的，因为我没有源代码。

我了解 Windows Azure 使用 64 位，所以我想知道这里迁移我的应用程序的最佳方法是什么？

即我应该将 32 位 DLL 移过来并依赖于 WoW64——这还能工作吗？我不介意性能受到小小的影响。

或者重新编译我的 64 位应用程序并以某种方式使用 32 位 DLL 会更好吗？

Answer 1

答案是肯定的。 Windows Azure 就像一个普通的 Windows Server 2008 x64，它有 32 位子系统。这里唯一的限制是 Web 角色和辅助角色托管进程是 64 位的。

考虑到这一点，您将不得不在 64 位主机进程和 32 位 DLL 之间进行某种互操作。当然，inproc COM 对象在这种情况下将不起作用。在不了解细节的情况下很难在这里给出更具体的建议：

1. 什么类型的 COM 接口（自动化兼容与否）？
2. 他们支持什么样的封送处理（仅限进程内或进程外）
3. 如果封送处理跨进程工作，您是否可以控制如何注册对象（进程内或进程外）。
4. 为您的对象创建托管包装器是多么容易（例如由 32 位进程托管并能够使用 WCF 或 COM 自动化与 64 位主机通信的自定义 C++/CLI 互操作程序集）

我不知道它是否会起作用，但要考虑的另一个选择是尝试强制您的应用程序池作为 32 位进程运行。您将需要以完全信任的方式在 IIS 模式下运行，并将其作为您的角色启动任务运行：
appcmd apppool 设置 /apppool.name: /enable32BitAppOnWin64:true
您必须确定将使用您的应用程序的应用程序池的名称。再说一次，我不确定这是否会起作用，但我想它值得一试，因为如果它有效，它将是你最简单的选择。

Answer 2

Windows Azure 培训工具包中的这个实验室"Advanced Web and Worker Roles" 介绍了在 Azure 中使用旧版 COM dll。