我在我的 Web 应用程序中使用大约 15-20 个旧版 32 位 C++ COM DLL，其中一些 32 位 DLL 具有第 3 方依赖项，这些依赖项是 DLL 的 COM 或本机依赖项。
我正在考虑迁移到 Windows Azure，据我所知，它是一个 64 位平台。谁能告诉我我的 32 位 DLL 是否可以工作？ （我知道现在可以 regsvr32 它们）。
经过一两周的工作，我可以将 DLL 重新编译为 64 位，但这对于第 3 方依赖项来说是不可能的，因为我没有源代码。
我知道 Windows Azure 使用 64 位，所以我想知道迁移我的应用程序的最佳方法是什么？
也就是说，我应该将 32 位 DLL 移过去并依赖 WoW64 - 这还能工作吗？我不介意性能受到一点影响。
或者重新编译我的 64 位应用程序会更好吗？somehow使用 32 位 DLL？
答案是肯定的。 Windows Azure 就像普通的 Windows Server 2008 x64 一样，它有 32 位子系统。这里唯一的限制是 Web 角色和辅助角色托管进程是 64 位。
考虑到这一点，您必须在 64 位主机进程和 32 位 DLL 之间进行某种互操作。当然，inproc COM 对象在这种情况下将不起作用。如果不了解细节，很难在这里给出更具体的建议：
- 什么类型的 COM 接口（自动化兼容或不兼容）？
- 他们支持什么样的编组（仅限进程内或进程外）
- 如果封送处理跨进程工作，您是否可以控制如何注册对象（进程内或进程外）。
- 为您的对象创建托管包装器有多容易（例如由 32 位进程托管并能够使用 WCF 或 COM 自动化与 64 位主机通信的自定义 C++/CLI 互操作程序集）
我不知道它是否有效，但要考虑的另一个选择是尝试强制应用程序池作为 32 位进程运行。您需要在完全信任的 IIS 模式下运行，并将其作为您的角色启动任务运行：
appcmd apppool set /apppool.name: /enable32BitAppOnWin64:true
您必须确定您的应用程序将使用的应用程序池的名称。再说一次，我不确定这是否有效，但我想值得一试，因为如果它有效，这对你来说将是最简单的选择。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
