Правильно или неправильно регистрировать 32-битный локальный сервер в 64-битной части реестра?

COM-объект, реализованный как 32-битный локальный сервер (.exe), регистрирующийся в 64-битных окнах, по умолчанию перенаправляется WOW64 (http://msdn.microsoft.com/en-us/library/aa384253.aspx). Когда клиент запрашивает экземпляр, система обычно выполняет поиск в обеих частях, если не установлены явные флаги контекста (CLSCTX_ACTIVATE _ ## _ BIT_SERVER).

Поэтому можно использовать 32-битные надстройки COM (реализованные как локальный сервер) с 64-битным MS Office 2010. Требуется только записать специальные ключи реестра MSO в 64-битную часть (KEY_WOW64_64KEY).

Поскольку MS Office 2013 64-битный, загружаются только COM-объекты, зарегистрированные в 64-битной части реестра, возможно, потому, что он явно запрашивает только 64-битные серверы. Кажется, что для этого ограничения нет оснований. Было ли это изменение между 2010 и 2013 годами случайно или намеренно?

Регистрация 32-битного локального сервера в 64-битной части решает проблему, но соответствует ли он правилам? Можно ли зарегистрировать 32-битный локальный сервер в 64-битной части или он должен быть в перенаправленной 32-битной части? Будет ли это игнорировать намерение клиента или это способ сообщить о совместимости с 64-битными клиентами?

Насколько я понимаю, MSO 2013 не хочет поддерживать 32-битные надстройки, хотя технически это возможно.

РЕДАКТИРОВАТЬ (чтобы быть более точным): я не спрашиваю, работает ли это (я знаю, что это так). Меня не интересуют уловки, позволяющие заставить работать вещи, для которых не предназначены. Это просто привело меня к вопросу, какие COM-объекты (локальный сервер, также известный как внепроцессный сервер) должны быть зарегистрированы в 64-битной части: те, которые реализованы в 64-битной версии, или те, которые могут использоваться 64-битными клиентами (даже если они реализованы в 32-битной версии). )?

РЕДАКТИРОВАТЬ (чтобы быть более общим): хотя мой вопрос относится к MSO как к клиенту, создающему объект COM, его можно задать в более общем плане. Представьте себе приложение, обеспечивающее автоматизацию, реализованное как 32-битный EXE. По умолчанию саморегистрация перенаправляется на Wow6432Node, но это не проблема. Когда клиент запрашивает экземпляр, он все равно будет найден системой (если клиент не ограничивается только 64-битными серверами). Поэтому обычно нет необходимости регистрироваться и на 64-битную часть, но разве это неправильно (для 32-битного EXE)? Что это значит, каковы последствия? Есть какие-то правила, рекомендации, ...?


person marx    schedule 07.10.2013    source источник


Ответы (1)


Совершенно нормально зарегистрировать 64-битную DLL-прокси в 64-битном реестре.

Только не регистрируйте 32-битную DLL-прокси в 64-битном реестре.

person Eric Brown    schedule 07.10.2013
comment
Я говорю не о DLL (inprocserver), а о EXE (localserver). Поскольку библиотеки DLL загружаются в адресное пространство вызывающего процесса, очевидно, что разрядность должна совпадать. С другой стороны, очевидно, что разрядность не имеет значения в межпроцессных сценариях (кстати: в предыдущих версиях WOW64 ключ HKLM \ ... \ CLASSID не только перенаправлялся, но и отражался, если не указывать сервер или обработчик inproc. в случае локальных серверов разницы не было.) Регистрация 32-битных EXE в 64-битной части работает, но соответствует ли она правилам? - person marx; 08.10.2013
comment
EXE должны иметь прокси DLL для обработки маршалинга. Поэтому единственное, что имеет значение, - это разрядность прокси-библиотеки DLL. - person Eric Brown; 08.10.2013
comment
Я не эксперт в COM, но, насколько я знаю (и опытен), прокси-библиотеки не являются обязательными. Мой COM-объект размещен в 32-битном EXE, который зарегистрирован с помощью ключа LocalServer32, без заглушек, прокси и т. Д. И он работает с 64-битным клиентом (MSO 2010 по умолчанию, MSO 2013 только при явной регистрации в 64-битной части). Я предполагаю, что сортировкой занимается система. - person marx; 08.10.2013
comment
@marx Это может быть правдой, если все ваши интерфейсы совместимы с автоматизацией. По моему опыту, мне всегда была нужна прокси DLL. - person Eric Brown; 08.10.2013