DLL не е регистриран при свързване към компютъра с различен акаунт

Мигрирам добавка VSTO OUTLOOK от 32-битова на 64-битова. Работи добре на Office 2007 32-bit. Целта е да работи на Office 365 64-bit.

Прекомпилирах добавката за 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 се регистрира със следния код:

    Dim WshShell

    Задайте WshShell = CreateObject("Wscript.Shell")

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

    Задайте WshShell = нищо


office365 windows-installer dll
person Sylvain Rodrigue    schedule 13.05.2019    source източник
comment
Чудя се дали изпълнението на regsvr32.exe чрез VBScript позволява на regsvr32.exe да се регистрира за всеки потребител. Не мисля, че regsvr32.exe може да направи това нормално. Странно. Сигурни ли сте, че COM-Extract at build не е бил включен през цялото време и това regsvr32.exe повикване никога не се е случило, тъй като може да сте задали персонализираното действие да игнорира грешки?   -  person Stein Åsmul    schedule 14.05.2019

Отговори (1)


arrow_upward
1
arrow_downward

Действителни стъпки: Само опитано, прагматично обобщение отгоре: 1: Докато сте влезли като втори потребител, опитайте да стартирате regedit.exe< /strong> и експортирайте HKCR (може и HKCU), след това регистрирайте COM dll, експортирайте отново и различете с подходящ инструмент за разлики (ако стартирането проработи изобщо е). 2: Изтеглете ProcMon.exe и наблюдавайте стартирането на вашето приложение/добавка, за да определите какво се случва. 3: Използвайте Visual Studio и преминете през и проверете изгледа Modules, за да определите какво се случва по време на стартирането. 4: Използвайте oleview.exe, за да видите каква регистрация изисква COM файлът (отворете вградения typelib). 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-Interop в същия списък, като зададете флага „.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