32 ビット ローカル サーバー (.exe) として実装され、64 ビット ウィンドウに自身を登録する COM オブジェクトは、既定で WOW64 によってリダイレクトされます ( http://msdn.microsoft.com/en-us/library/aa384253.aspx )。クライアントがインスタンスを要求すると、明示的なコンテキスト フラグが設定されていない限り (CLSCTX_ACTIVATE_##_BIT_SERVER)、システムは通常両方の部分を検索します。
したがって、MS Office 2010 64 ビットで 32 ビット COM アドイン (ローカル サーバーとして実装) を使用することができます。MSO 固有のレジストリ キーを 64 ビット部分にも書き込む必要があるだけです (KEY_WOW64_64KEY)。
MS Office 2013 64 ビット以降、64 ビット レジストリ部分に登録されている COM オブジェクトのみがロードされます。これは、64 ビット サーバーのみを明示的に要求している可能性があります。この制限の理由はないようです。2010 年から 2013 年にかけて行われたこの変更は、偶然または意図的に行われたものですか?
32bitのローカルサーバーを64bit部分に登録すれば問題は解決しますが、ルールは守られていますか？32 ビットのローカル サーバーを 64 ビット パーツに登録できますか、それともリダイレクトされた 32 ビット パーツに登録する必要がありますか? クライアントの意図を無視しますか、それとも 64 ビット クライアントとの互換性を示す方法ですか?
私の知る限り、技術的には可能ですが、MSO 2013 は 32 ビット アドインをサポートしたくありません。
編集（より正確に言うと）：それが機能するかどうかは尋ねていません（機能することはわかっています）。意図されていないことを機能させるためのトリックには興味がありません。どのCOMオブジェクト（ローカルサーバー、別名アウトプロセスサーバー）を64ビット部分に登録する必要があるかという質問に私を導きました：64ビットで実装されたもの、または64ビットクライアントで使用できるもの（32ビットで実装されていても） )?
EDIT（より一般的に）：私の質問はMSOをCOMオブジェクトをインスタンス化するクライアントと呼んでいますが、より一般的に尋ねることができます。32 ビット EXE として実装された自動化を提供するアプリケーションを考えてみてください。デフォルトでは、自己登録は Wow6432Node にリダイレクトされますが、問題ありません。クライアントがインスタンスを要求すると、システムによって検出されます (クライアントが 64 ビット サーバーのみに制限されている場合を除く)。そのため、通常は 64bit 部分にも登録する必要はありませんが、(32bit EXE の場合) 間違っているのでしょうか? それはどういう意味ですか、結果は何ですか？規則、推奨事項などはありますか?