在64位窗口上实现为32位本地服务器（.exe）实现的COM对象默认由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 64bit仅加载了64位注册表部分中注册的COM对象，可能是因为它仅显式请求64位服务器。这种限制似乎没有理由。 2010年和2013年之间的这种变化是偶然还是故意的？
将32位本地服务器注册到64位部分可以解决问题，但它是否符合规则？是否可以在64位部分注册32位本地服务器，还是必须在重定向的32位部分？它是否会忽视客户的意图，还是一种向64位客户发出兼容性信号的方式？
据我了解，MSO 2013不希望支持32位插件，尽管技术上可能。
编辑（更准确地说）：我不是在问它是否有效（我知道它确实如此）。我并不感兴趣的做法是让事情无法发挥作用。它只是让我想到了哪些COM对象（本地服务器，也称为进程外服务器）应该在64位部分注册的问题：64位实现的那些或64位客户端可以使用的那些（即使它们是以32位实现的） ）？编辑（更一般）：虽然我的问题是将MSO称为客户端实例化COM对象，但可以更普遍地询问它。想象一下提供自动化的应用程序，实现为32位EXE。默认情况下，它的自我注册被重定向到Wow6432Node，但这没问题。当客户端请求实例时，系统仍会找到它（除非客户端仅限制为64位服务器）。因此，通常没有必要注册到64位部分，但它是错误的（对于32位EXE）？这是什么意思，后果是什么？有没有规则，建议......？
答案 0 :(得分：0)
在64位注册表中注册64位代理DLL是完全可以的。
只是不要在64位注册表中注册32位代理DLL。