DLL не регистрируется при подключении к компьютеру с другой учетной записью

Я переношу надстройку VSTO OUTLOOK с 32-разрядной на 64-разрядную. Он хорошо работает в 32-разрядной версии Office 2007. Наша цель - запустить его в 64-разрядной версии Office 365.

Я перекомпилировал надстройку для 64-битной платформы и обновил проект installshield.

Когда я устанавливаю надстройку на новый компьютер с Windows 10, используя свою учетную запись (у меня есть права администратора), она работает нормально. Я вижу это в Outlook и могу им пользоваться.

Однако, если я выхожу из системы и попрошу кого-то еще войти в систему на машине сохранения (этот кто-то другой также имеет права администратора), надстройка отображается в Outlook, но эта ошибка отображается, когда пользователь ее использует:

System.Runtime.InteropServices.COMException (0x80040154): получение фабрики классов COM для компонента с CLSID {29AB7A12-B531-450E-8F7A-EA94C2F3C05F} не удалось из-за следующей ошибки: 80040154 Класс не зарегистрирован ( Исключение из HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

Любая идея?

Подробности:

  • Эта надстройка использует только одну внешнюю DLL: 64-битную DLL от Redemption.
  • Решение было скомпилировано в Visual Studio 2015. Целевая платформа: x64.
  • Чтобы установить его на компьютер, я использую MSI, созданный с помощью InstallShield Express в Visual Studio 2015.
  • В InstallShield я указал ALLUSERS-1 (установка на компьютере).
  • DLL регистрируется с использованием следующего кода:

    Тусклый WshShell

    Установите WshShell = CreateObject ("Wscript.Shell")

    WshShell.run "regsvr32 / s" "C: \ Program Files (x86) \ MyCompany \ AddInName \ Redemption64.dll"

    Установите WshShell = ничего


person Sylvain Rodrigue    schedule 13.05.2019    source источник
comment
Интересно, позволяет ли запуск regsvr32.exe через VBScript regsvr32.exe регистрировать каждого пользователя. Я не думаю, что regsvr32.exe может делать это нормально. Странный. Вы уверены, что Извлечение COM при сборке не было постоянно и этот regsvr32.exe вызов никогда не выполнялся, поскольку вы, возможно, настроили настраиваемое действие для игнорирования ошибок?   -  person Stein Åsmul    schedule 14.05.2019


Ответы (1)


Фактические шаги: просто попытка прагматического вывода вверху: 1: Войдя в систему как второй пользователь, попробуйте запустить regedit.exe < / strong> и экспортировать HKCR (возможно, HKCU), затем зарегистрируйте COM dll, снова экспортируйте и сравните с подходящим инструментом сравнения (если запуск вообще сработал, является). 2: Загрузите ProcMon.exe и отслеживайте запуск своего приложения / надстройки, чтобы определить, что происходит. 3: Используйте Visual Studio и пошагово проверяйте представление Modules, чтобы определить, что происходит во время запуска. 4: Используйте oleview.exe, чтобы узнать, какая регистрация требуется для COM-файла (откройте встроенную библиотеку типов). File => View Typelib.... Подробности ниже.


Быстрая проверка: возможно, сначала проверьте следующее: Outlook Redemption - использование RedemptionLoader без regsvr32 DLL.

Кроме того, вы отключили все до того, как второй пользователь вошел в систему? Или вы просто поменяли пользователей? Возможно, попробуйте оба варианта, убедитесь, что при первом входе в систему ничего не загружено и не заблокировано.

Приведенная ниже «отладка регистрации» может не попасть в цель. Похоже, это могло быть что-то более странное. Может, просто просмотрите его.

Мнемоника развертывания: попробуйте это мнемоника развертывания. Небольшой абзац с напоминаниями о том, как можно думать, чтобы попытаться решить проблемы развертывания: "What is locking, what is blocking, what is missing, etc..."


Регистрация. Хотя это выглядит как просто отсутствующая регистрация, это могло быть что-то более странное. У меня есть контрольный список запуска приложений , который можно просмотреть. Не написано для надстроек, но может дать вам некоторые идеи.

Саморегистрация. Самостоятельная регистрация не рекомендуется для регистрации через COM, как описано здесь: MSI register dll - саморегистрация считается вредоносной. В Installshield вы можете просто зарегистрировать COM-файл, извлекая COM-данные при сборке, как показано на изображении ниже. Вы также можете включить регистрацию COM-взаимодействия в том же списке, установив флаг «.NET COM Interop» на yes:

Извлечение COM.

< em> COM Interop: сборки .NET можно зарегистрировать для использования COM с помощью regasm.exe. Это (почти) то же самое, что и для упомянутого выше параметра .NET COM Interop, установленного на "yes". Если вы хотите использовать COM-файл из .NET, вам необходимо сгенерировать файл сборки Interop, а затем установить и зарегистрировать настоящий COM-файл (что вы и делаете). Обе операции должны быть выполнены.

Закидываем пару ссылок. Эти (древние) статьи посвящены использованию regasm.exe, tlbexp.exe, tlbimp.exe и gacutil.exe. Вам не нужно, но оставлю для справки:


Некоторые ссылки:

person Stein Åsmul    schedule 13.05.2019
comment
Замечательный комментарий! Наконец, я использовал ProcMon и увидел, что DLL зарегистрирована под HKCU, но не под HKLM. Недостаточно установить MSI с учетной записью администратора. Он отлично работает для всех пользователей, если я запускаю установку из командной строки с повышенными привилегиями: msiexec.exe / i c: \ setup.msi / QN / L * V C: \ Temp \ MyAddIn.log. Спасибо за (многочисленные) указатели! - person Sylvain Rodrigue; 14.05.2019
comment
Рад, что это помогло, я воспользовался возможностью, чтобы написать ответ на попытку повторного использования. Мне было интересно, был ли этот HKCU виноват - это очень простая проблема. Я знаю только, что msiexec.exe может регистрировать компоненты COM для каждого пользователя, кстати, regsvr32.exe не может этого делать, насколько мне известно. Вы должны удалить это настраиваемое действие, чтобы зарегистрировать COM-файл с помощью regsvr32.exe и, кстати, полагаться на извлечение COM. - person Stein Åsmul; 14.05.2019