Объект COM, реализованный как 32-разрядный локальный сервер (.exe), регистрирующий себя на 64-битных окнах, перенаправляется WOW64 по умолчанию (http://msdn.microsoft.com/en-us/library/aa384253.aspx). Когда клиент запрашивает экземпляр, система обычно будет искать в обеих частях, если не установлены явные флаги контекста (CLSCTX_ACTIVATE _ ## _ BIT_SERVER).Правильно или неправильно регистрировать 32-битный локальный сервер в 64-битной части реестра?
Поэтому можно использовать 32-битные COM-дополнения (реализованные как локальные серверы) с MS Office 2010 64bit. Для этого требуется только запись специальных разделов реестра MSO в 64-разрядную часть (KEY_WOW64_64KEY).
С MS Office 2013 загружаются только 64-битные объекты COM, зарегистрированные в 64-разрядной части реестра, возможно, потому, что они явно запрашивают только 64-битные серверы. Кажется, нет никаких оснований для этого ограничения. Было ли это изменение между 2010 и 2013 годами сделано случайно или преднамеренно?
Регистрация 32-разрядного локального сервера в 64-разрядной части решает проблему, но соответствует ли она правилам? Может ли 32-битный локальный сервер быть зарегистрирован в 64-битной части или должен быть в перенаправленной 32-битной части? Будет ли это игнорировать намерение клиента или это способ сигнализировать о совместимости с 64-битными клиентами?
Насколько я понимаю, MSO 2013 не хочет поддерживать 32-битные дополнения, хотя технически возможно.
EDIT (если быть более точным): Я не спрашиваю, работает ли это (я знаю, что это так). Меня не интересуют трюки, чтобы заставить вещи работать, на которые не предназначены. Это просто приводит меня к вопросу о том, какие COM-объекты (локальный сервер, например, сервер вне процесса) должны быть зарегистрированы в 64-битной части: те, которые реализованы на 64-битной или те, которые могут использоваться 64-битными клиентами (даже если они реализованы в 32-битной)?
EDIT (чтобы быть более общим): хотя мой вопрос относится к MSO как клиент, запугающий COM-объект, его можно задать в более общем плане. Подумайте о автоматизации приложений, реализованной как 32-разрядный EXE. По умолчанию его саморегистрация перенаправляется на Wow6432Node, но это не проблема. Когда клиент запрашивает экземпляр, он все равно будет найден системой (если только клиент не ограничивается только 64-битными серверами). Поэтому, как правило, нет необходимости регистрироваться и на 64-битной части, но это неправильно (для 32-битного EXE)? Что это значит, каковы последствия? Существуют ли какие-либо правила, рекомендации, ...?
Я не говорю о DLL (inprocserver), но EXEs (localserver). Поскольку DLL загружаются в адресное пространство процесса вызова, очевидно, что битность должна соответствовать. Поскольку, с другой стороны, очевидно, что битнес не имеет значения в сценариях межсетевого взаимодействия (кстати, в предыдущих версиях WOW64 ключ HKLM \ ... \ CLASSID был не только перенаправлен, но и отражен, если не указывать сервер или обработчик inproc. не было никакой разницы в случае локальных серверов.) Регистрация 32-разрядных EXE в 64-битной части действительно работает, но соответствует ли она правилам? – marx
EXE должны иметь прокси-библиотеки для обработки маршалинга. Итак, единственное, что имеет значение, - это битту прокси-библиотеки DLL. –
Я не эксперт в COM, но насколько я знаю (и опытные) прокси-библиотеки DLL не являются обязательными. Мой COM-объект размещен в 32-битном EXE, который зарегистрирован с помощью ключа LocalServer32, без заглушек, прокси и т. Д. И он работает с 64-битным клиентом (MSO 2010 по умолчанию, MSO 2013 только при явной регистрации в 64-битной части тоже). Я предполагаю, что сортировка обрабатывается системой. – marx