Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FDSC, Вы писали:
VD>4. Word 64-битный. Тут только установка 32-битного ворда поможет.
VD>Если ни один варианта не поможет, будем думать дальше.
Прошу прощения, а можно доработать authority pack для поддержки 64-битной OS и офиса? Как-то это перебор, ставить параллельно с 64-битным ещё и 32-битный офис только лишь для написания статьи на rsdn. Или поднимать виртуалку с 32-битной системой...
Здравствуйте, SGHouse, Вы писали:
SGH>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, FDSC, Вы писали:
VD>>4. Word 64-битный. Тут только установка 32-битного ворда поможет.
VD>>Если ни один варианта не поможет, будем думать дальше.
SGH>Прошу прощения, а можно доработать authority pack для поддержки 64-битной OS и офиса? Как-то это перебор, ставить параллельно с 64-битным ещё и 32-битный офис только лишь для написания статьи на rsdn. Или поднимать виртуалку с 32-битной системой...
Сорри, ошибся в названии — authority pack -> Authoring Pack.
Здравствуйте, SGHouse, Вы писали:
SGH>Прошу прощения, а можно доработать authority pack для поддержки 64-битной OS и офиса? Как-то это перебор, ставить параллельно с 64-битным ещё и 32-битный офис только лишь для написания статьи на rsdn. Или поднимать виртуалку с 32-битной системой...
Офторп: Вообще-то МС сам не рекомендует ставить 64-ый офис (прямо в инсталляторе).
Проблема в том, что наше расширение, по идее, не должно зависеть от битности офиса. Оно написано на дотнете и ВБА. Но, почему-то, я уже слышу третий отклик о том, что оно не работает под 64-битным офисом. Причем у меня нет идей как понять, что не так. Там COM. А он не прозрачен до чертиков.
Попытаюсь поставить себе (еще раз) 64-битный офис и пошаманить. Но обещать ничего не могу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, SGHouse, Вы писали:
SGH>>Прошу прощения, а можно доработать authority pack для поддержки 64-битной OS и офиса? Как-то это перебор, ставить параллельно с 64-битным ещё и 32-битный офис только лишь для написания статьи на rsdn. Или поднимать виртуалку с 32-битной системой...
VD>Офторп: Вообще-то МС сам не рекомендует ставить 64-ый офис (прямо в инсталляторе).
VD>Проблема в том, что наше расширение, по идее, не должно зависеть от битности офиса. Оно написано на дотнете и ВБА. Но, почему-то, я уже слышу третий отклик о том, что оно не работает под 64-битным офисом. Причем у меня нет идей как понять, что не так. Там COM. А он не прозрачен до чертиков.
VD>Попытаюсь поставить себе (еще раз) 64-битный офис и пошаманить. Но обещать ничего не могу.
Я, конечно, в дотнете не силён, но попробую помочь предположениями.
Хотя дотнет проекты по натуре кросс-платформенны, но почему-то у меня в Visual Studio 2008 в настройках C#-проекта в разделе "построение" есть такая интересная опция "конечная платформа"... И там можно выбрать "Any CPU", "x32", "x64". Собственно, первый вопросец: у Вас проект собирается под Any CPU?
Есть несколько типов COM-объектов, один из них — это inproc. По сути это обыкновенная dll'ка. 32-разрядную dll-ку можно подгрузить только 32-разрядный процесс, а 64-разрядную — в, соответственно, 64-разрядный. А потому в 64-разрядной OS в том, что относится к регистрации COM-компонентов, есть две, дублирующие друг друга, ветви реестра. Если приложение 32-разрядное, то при вызове COM-библиотеки ему "подставляется" один вариант ветви, а если 64-разрядное — другой. И получается ошибка "не могу создать ActiveX компонент".
Могу предположить следующее: Ваша dll регистрируется как inproc-сервер в COM-ветви для 32-разрядных приложений. А 64-разрядный MS Word, выполняя макрос и пытаясь создать соответствующий COM-объект, обращается к 64-разрядной COM-ветви реестра.
Здравствуйте, SGHouse, Вы писали:
SGH>Хотя дотнет проекты по натуре кросс-платформенны, но почему-то у меня в Visual Studio 2008 в настройках C#-проекта в разделе "построение" есть такая интересная опция "конечная платформа"... И там можно выбрать "Any CPU", "x32", "x64". Собственно, первый вопросец: у Вас проект собирается под Any CPU?
Ну, я вообще-то и в донтете, и в студии, и ком разбираюсь довольно хорошо. Естественно, сборки Any CPU. Правда, в них есть микроскопический объем платформно-зависимого кода. В нем, конечно, возможна ошибка. Но в любом случае они не должны были бы приводить к тому что сборку нельзя загрузить. Должны были бы быть рантайм-ылеты.
Как, кстати, выглядят проблемы с шаблоном в 64-битном Офисе? Говорит, что не может создать объект?
SGH>Есть несколько типов COM-объектов, один из них — это inproc. По сути это обыкновенная dll'ка.
Я в курсе. Если заглянуть в список моих статей, то можно заметить, что 10 лет назад я плотно занимался КОМ-ом.
SGH>32-разрядную dll-ку можно подгрузить только 32-разрядный процесс, а 64-разрядную — в, соответственно, 64-разрядный. А потому в 64-разрядной OS в том, что относится к регистрации COM-компонентов, есть две, дублирующие друг друга, ветви реестра. Если приложение 32-разрядное, то при вызове COM-библиотеки ему "подставляется" один вариант ветви, а если 64-разрядное — другой. И получается ошибка "не могу создать ActiveX компонент".
Приложение дотнетное. Потому и не понятно, почему не работает. Возможно проблемы с регистрацией. Регистрация делается встроенным студийным инсталлятором (из VS 2008). У сборки просто установлено свойство Register установлено в vsdrpCOM. Что он там делает я не знаю.
SGH>Могу предположить следующее: Ваша dll регистрируется как inproc-сервер в COM-ветви для 32-разрядных приложений. А 64-разрядный MS Word, выполняя макрос и пытаясь создать соответствующий COM-объект, обращается к 64-разрядной COM-ветви реестра.
Возможно.
Как посмотреть HKEY_CLASSES_ROOT для 64-битных комовских сборок?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, SGHouse, Вы писали:
SGH>>Хотя дотнет проекты по натуре кросс-платформенны, но почему-то у меня в Visual Studio 2008 в настройках C#-проекта в разделе "построение" есть такая интересная опция "конечная платформа"... И там можно выбрать "Any CPU", "x32", "x64". Собственно, первый вопросец: у Вас проект собирается под Any CPU?
VD>Ну, я вообще-то и в донтете, и в студии, и ком разбираюсь довольно хорошо. Естественно, сборки Any CPU. Правда, в них есть микроскопический объем платформно-зависимого кода. В нем, конечно, возможна ошибка. Но в любом случае они не должны были бы приводить к тому что сборку нельзя загрузить. Должны были бы быть рантайм-ылеты.
VD>Как, кстати, выглядят проблемы с шаблоном в 64-битном Офисе? Говорит, что не может создать объект?
SGH>>Есть несколько типов COM-объектов, один из них — это inproc. По сути это обыкновенная dll'ка.
VD>Я в курсе. Если заглянуть в список моих статей, то можно заметить, что 10 лет назад я плотно занимался КОМ-ом.
Прошу прощения, если мои предположения оказались чересчур тривиальными.
SGH>>32-разрядную dll-ку можно подгрузить только 32-разрядный процесс, а 64-разрядную — в, соответственно, 64-разрядный. А потому в 64-разрядной OS в том, что относится к регистрации COM-компонентов, есть две, дублирующие друг друга, ветви реестра. Если приложение 32-разрядное, то при вызове COM-библиотеки ему "подставляется" один вариант ветви, а если 64-разрядное — другой. И получается ошибка "не могу создать ActiveX компонент".
VD>Приложение дотнетное. Потому и не понятно, почему не работает. Возможно проблемы с регистрацией. Регистрация делается встроенным студийным инсталлятором (из VS 2008). У сборки просто установлено свойство Register установлено в vsdrpCOM. Что он там делает я не знаю.
SGH>>Могу предположить следующее: Ваша dll регистрируется как inproc-сервер в COM-ветви для 32-разрядных приложений. А 64-разрядный MS Word, выполняя макрос и пытаясь создать соответствующий COM-объект, обращается к 64-разрядной COM-ветви реестра.
VD>Возможно.
VD>Как посмотреть HKEY_CLASSES_ROOT для 64-битных комовских сборок?
VD>ЗЫ
VD>Со своей стороны хочу попробовать описанные здесь действия. Есть проблема связанная с выбором версии дотнета вордовским процессом. Возможно причина именно в ней, а не в 64-битности.
VD>Так же прошу как можно боле подробно описать симптомы возникающие в 64-битном ворде.
Я смог запустить Ваш код на 64-битном ворде. Проблема не в дотнет-сборке, она, действительно, работает прозрачно и на 32- и на 64-битной платформе. Проблема и не в выборе версии дотнета. Вашу рекомендацию (здесь
) я попробовал ещё до того, как написать сюда первое сообщение.
Проблема в регистрации. Подробно про маппинг ветвей реестра я нашёл здесь. В деталях ситуация следующая. Я поставил AuthoringPack "just for me", и он зарегистрировал свой ProgId в ветви HKCU\Software\Classes\RsdnMlAutomation. CLSID {xxx}, указанный там, ссылается на HKCU\Software\Classes\Wow6432Node\CLSID\{xxx}, что объясняется информацией, приведённой по ссылке выше. Получается, что 32-битное приложение, обращаясь к HKCU\Software\Classes\CLSID\{xxx} в реальности обращается в ...\Wow6432Node\... (маппинг делается OS) и получает весь блок информации этого CLSID'а. А 64-битное приложение обращается к реальной ветви HKCU\Software\Classes\CLSID\, а там CLSID'а {xxx} нет. В итоге, просто скопировав этот ключ из HKCU\Software\Classes\Wow6432Node\CLSID\ в HKCU\Software\Classes\CLSID\ я получил нормально работающий AuthoringPack.
Здравствуйте, SGHouse, Вы писали:
SGH>Проблема в регистрации. Подробно про маппинг ветвей реестра я нашёл здесь. В деталях ситуация следующая. Я поставил AuthoringPack "just for me", и он зарегистрировал свой ProgId в ветви HKCU\Software\Classes\RsdnMlAutomation. CLSID {xxx}, указанный там, ссылается на HKCU\Software\Classes\Wow6432Node\CLSID\{xxx}, что объясняется информацией, приведённой по ссылке выше. Получается, что 32-битное приложение, обращаясь к HKCU\Software\Classes\CLSID\{xxx} в реальности обращается в ...\Wow6432Node\... (маппинг делается OS) и получает весь блок информации этого CLSID'а. А 64-битное приложение обращается к реальной ветви HKCU\Software\Classes\CLSID\, а там CLSID'а {xxx} нет. В итоге, просто скопировав этот ключ из HKCU\Software\Classes\Wow6432Node\CLSID\ в HKCU\Software\Classes\CLSID\ я получил нормально работающий AuthoringPack.
Спасибо за помощь!
В ближайшее время постараюсь описать ситуацию в статье, а потом попробую придумать что-то, чтобы инсталлятор правильно регистрировал КОМ-объекты в реестре. Боюсь, что придется переходить с инсталлятор встроенного в студию на Wix.
Хотелось бы еще попросить проверить корректность работы самой интеграции в 64-битном окружении (так как она не тестировалась).
Попробуйте сгенерировать ХМЛ (нажать соответствующую кнопку в тулбаре) с ошибками. При этом должно появиться окно со списком ошибок. Далее попробуйте изменить размеры этого окна. Дело в том, что там используется хак. Окна форм в ворде не ресайзятся. Я использовал SetWindowLong(hwnd, GWL_STYLE, L2 :> IntPtr); для того чтобы можно было изменять их размеры. Причем код там не тривиальный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, SGHouse, Вы писали:
SGH>Проблема в регистрации. Подробно про маппинг ветвей реестра я нашёл здесь. В деталях ситуация следующая. Я поставил AuthoringPack "just for me", и он зарегистрировал свой ProgId в ветви HKCU\Software\Classes\RsdnMlAutomation. CLSID {xxx}, указанный там, ссылается на HKCU\Software\Classes\Wow6432Node\CLSID\{xxx}, что объясняется информацией, приведённой по ссылке выше. Получается, что 32-битное приложение, обращаясь к HKCU\Software\Classes\CLSID\{xxx} в реальности обращается в ...\Wow6432Node\... (маппинг делается OS) и получает весь блок информации этого CLSID'а. А 64-битное приложение обращается к реальной ветви HKCU\Software\Classes\CLSID\, а там CLSID'а {xxx} нет. В итоге, просто скопировав этот ключ из HKCU\Software\Classes\Wow6432Node\CLSID\ в HKCU\Software\Classes\CLSID\ я получил нормально работающий AuthoringPack.
Кстати, сделайте, пожалуйста, экспорт этой (этих) веток в формате regex.exe. Чтобы другие могли им воспользоваться пока не решим проблем с инсталлятором.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Боюсь, что придется переходить с инсталлятор встроенного в студию на Wix.
.\snippets\WordToRsdnMlConverter\Setup\Setup.vdproj — это оно? Я со встроенным в студию деплоем не работал, но, на первый взгляд, перетащить это на Wix — не проблема, давай сделаю (с учетом этого обсуждения по поводу реестра)?
Здравствуйте, kochetkov.vladimir, Вы писали:
VD>>Боюсь, что придется переходить с инсталлятор встроенного в студию на Wix.
KV>.\snippets\WordToRsdnMlConverter\Setup\Setup.vdproj — это оно? Я со встроенным в студию деплоем не работал, но, на первый взгляд, перетащить это на Wix — не проблема, давай сделаю (с учетом этого обсуждения по поводу реестра)?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, SGHouse, Вы писали:
SGH>>Проблема в регистрации. Подробно про маппинг ветвей реестра я нашёл здесь. В деталях ситуация следующая. Я поставил AuthoringPack "just for me", и он зарегистрировал свой ProgId в ветви HKCU\Software\Classes\RsdnMlAutomation. CLSID {xxx}, указанный там, ссылается на HKCU\Software\Classes\Wow6432Node\CLSID\{xxx}, что объясняется информацией, приведённой по ссылке выше. Получается, что 32-битное приложение, обращаясь к HKCU\Software\Classes\CLSID\{xxx} в реальности обращается в ...\Wow6432Node\... (маппинг делается OS) и получает весь блок информации этого CLSID'а. А 64-битное приложение обращается к реальной ветви HKCU\Software\Classes\CLSID\, а там CLSID'а {xxx} нет. В итоге, просто скопировав этот ключ из HKCU\Software\Classes\Wow6432Node\CLSID\ в HKCU\Software\Classes\CLSID\ я получил нормально работающий AuthoringPack.
VD>Кстати, сделайте, пожалуйста, экспорт этой (этих) веток в формате regex.exe. Чтобы другие могли им воспользоваться пока не решим проблем с инсталлятором.
В каком формате? Наверное, regedit.exe? Экспорт в аттаче. Однако нужно помнить, это пути там к установке получаются жёстко прописанными. Кто ставит в другую директорию, работать не будет. Кроме того деинсталляции для этого "хака" нет.
Здравствуйте, SGHouse, Вы писали:
SGH>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, SGHouse, Вы писали:
SGH>>>Проблема в регистрации. Подробно про маппинг ветвей реестра я нашёл здесь. В деталях ситуация следующая. Я поставил AuthoringPack "just for me", и он зарегистрировал свой ProgId в ветви HKCU\Software\Classes\RsdnMlAutomation. CLSID {xxx}, указанный там, ссылается на HKCU\Software\Classes\Wow6432Node\CLSID\{xxx}, что объясняется информацией, приведённой по ссылке выше. Получается, что 32-битное приложение, обращаясь к HKCU\Software\Classes\CLSID\{xxx} в реальности обращается в ...\Wow6432Node\... (маппинг делается OS) и получает весь блок информации этого CLSID'а. А 64-битное приложение обращается к реальной ветви HKCU\Software\Classes\CLSID\, а там CLSID'а {xxx} нет. В итоге, просто скопировав этот ключ из HKCU\Software\Classes\Wow6432Node\CLSID\ в HKCU\Software\Classes\CLSID\ я получил нормально работающий AuthoringPack.
VD>>Кстати, сделайте, пожалуйста, экспорт этой (этих) веток в формате regex.exe. Чтобы другие могли им воспользоваться пока не решим проблем с инсталлятором.
SGH>В каком формате? Наверное, regedit.exe? Экспорт в аттаче. Однако нужно помнить, это пути там к установке получаются жёстко прописанными. Кто ставит в другую директорию, работать не будет. Кроме того деинсталляции для этого "хака" нет.
Если аттач не прикрепился, вот, на всякий случай, содержимое. Благо, оно небольшое.
Здравствуйте, SGHouse, Вы писали:
VD>>Кстати, сделайте, пожалуйста, экспорт этой (этих) веток в формате regex.exe. Чтобы другие могли им воспользоваться пока не решим проблем с инсталлятором.
SGH>В каком формате? Наверное, regedit.exe? Экспорт в аттаче.
В каком еще атаче? Это же форум.
SGH>Однако нужно помнить, это пути там к установке получаются жёстко прописанными. Кто ставит в другую директорию, работать не будет. Кроме того деинсталляции для этого "хака" нет.
Это, я думаю, должно быть понятно тем кто захочет использовать этот скрипт.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
