作为 32 位本地服务器 (.exe) 实现的 COM 对象在 64 位窗口上注册自身，默认情况下会被 WOW64 重定向 (http://msdn.microsoft.com/en-us/library/aa384253.aspx)。当客户端请求实例时，系统通常会在两个部分进行搜索，除非设置了明确的上下文标志 (CLSCTX_ACTIVATE_##_BIT_SERVER)。
因此，可以将 32 位 COM 插件(作为本地服务器实现)与 MS Office 2010 64 位一起使用。它只需要将 MSO 特定的注册表项也写入 64 位部分 (KEY_WOW64_64KEY)。
自 MS Office 2013 64 位以来，仅加载在 64 位注册表部分中注册的 COM 对象，可能是因为它仅明确请求 64 位服务器。这种限制似乎没有任何理由。 2010 年和 2013 年之间的这种变化是无意的还是有意的？
将32bit本地服务器注册到64bit部分解决了问题，但是是否符合规则？ 32 位本地服务器可以在 64 位部分注册还是必须在重定向的 32 位部分？它会无视客户的意图，还是表示与 64 位客户端兼容的一种方式？
据我了解，MSO 2013 不希望支持 32 位插件，尽管在技术上是可能的。
编辑(更准确地说):我不是在问它是否有效(我知道它有效)。我对使非预期工作的技巧不感兴趣。它只是让我想到应该在 64 位部分注册哪些 COM 对象(本地服务器，也称为进程外服务器)的问题:那些在 64 位中实现的对象或那些可以被 64 位客户端使用的对象(即使它们是在 32 位中实现的) )?
编辑(更笼统):尽管我的问题将 MSO 称为实例化 COM 对象的客户端，但可以更笼统地提出这个问题。考虑一个提供自动化的应用程序，实现为 32 位 EXE。默认情况下，它的 self 注册被重定向到 Wow6432Node，但这没问题。当客户端请求一个实例时，系统无论如何都会找到它(除非客户端仅限于 64 位服务器)。因此通常也不需要注册到 64 位部分，但它是错误的(对于 32 位 EXE)吗？什么意思，有什么后果？是否有任何规则、建议……？
最佳答案
在 64 位注册表中注册 64 位代理 DLL 是完全可以的。
只是不要在 64 位注册表中注册 32 位代理 DLL。
关于windows - 在64位注册表部分注册32位本地服务器是对还是错？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19222270/