使用其他帐户连接到计算机时未注册DLL [英] DLL not registered when connecting to the computer with a different account

查看：64
本文介绍了使用其他帐户连接到计算机时未注册DLL的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我正在将VSTO OUTLOOK加载项从32位迁移到64位.它在32位Office 2007上运行良好.目标是使其在64位Office 365上运行.

我已经为64位平台重新编译了该插件，并更新了installshield项目.

当我使用自己的帐户(具有管理员权限)在新的Windows 10计算机上安装外接程序时，工作正常.我可以在Outlook中看到它，也可以使用它.

但是，如果我注销并要求其他人登录保存机(该其他人也具有管理员权限)，则该加载项会显示在Outlook中，但是当用户使用它时会显示此错误:

System.Runtime.InteropServices.COMException(0x80040154):正在检索 具有CLSID的组件的COM类工厂 由于以下原因，{29AB7A12-B531-450E-8F7A-EA94C2F3C05F}失败 错误:80040154 未注册类(HRESULT的异常: 0x80040154(REGDB_E_CLASSNOTREG).

有什么主意吗?

详细信息:

  • 此加载项仅使用一个外部DLL:Redemption的64位DLL.
  • 该解决方案已在Visual Studio 2015中编译.平台目标:x64.
  • 要将其安装在计算机上，我使用在Visual Studio 2015上使用InstallShield Express创建的MSI.
  • 在InstallShield中，我指定了ALLUSERS-1(按机器安装).

  • 使用以下代码注册DLL:

    昏暗的WshShell

    设置WshShell = CreateObject("Wscript.Shell")

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

    设置WshShell =无

解决方案

实际步骤 :上面只是一个尝试性的，实用的摘要: 1: 以第二个用户身份登录时，尝试启动 regedit.exe 并导出 HKCR (也可能是 HKCU )，然后注册COM dll，再次导出并用合适的diff工具(如果启动完全成功的话). 2: 下载> ProcMon.exe ，并监视您的应用程序/加载项启动以确定正在发生的情况. 3: 使用Visual Studio和逐步操作，并检查 Modules 视图以确定启动过程中发生了什么. 4: 使用 oleview.exe 查看COM文件需要进行哪些注册(打开嵌入式typelib). File => View Typelib... .下面有更多详细信息.

快速检查 :也许先检查一下:

部署助记符 :也许可以尝试以下

注册 :尽管这看起来像是简单的缺少注册，但可能更奇怪.我有这个 应用程序启动检查列表 ，您可以浏览.不是为外接程序编写的，但可能会给您一些想法.

  • regsvr32.exe :您是否尝试以第二个用户的身份手动运行 regsvr32.exe 来检查其是否有效?尽管可以为每个用户注册一个COM文件，但我不知道使用 regsvr32.exe 这样做的方法是可靠的.
  • ProcMon.exe :您是否熟悉使用 ProcMon.exe ?她是 基本示例 .然后 Hanselman展示如何完成(YouTube) .您可以使用它来尝试确定失败的原因和时间.需要进行一些练习才能有效地使用，但这是我的第一和最后的手段".
  • Visual Studio :我喜欢使用Visual Studio逐步遍历代码，并在不同的窗口(例如模块)中查看，以了解应用程序的工作原理，因此确定在启动过程中可能出了什么问题.

  • oleview.exe :要弄清楚COM文件在自注册过程中的注册内容，有几种方法.以管理员权限启动 oleview.exe ，然后转到 File => View Typelib... ，然后找到您要检查并打开的COM文件为您提供了嵌入式 RegSpy2.exe :您也可以使用 RegSpy2.exe COM注册提取. 在此处查看示例.

  • 捕获比较 :最后可以使用安装程序捕获工具进行调试.它在更改之前和更改之后扫描注册表(和磁盘).换句话说，您确定基准，注册dll，然后扫描差异.可靠的工具非常昂贵(AdminStudio，Advanced Installer Architecht等).穷人的设置或注册捕获版本是在使用 regedit.exe 之前和之后导出 HKCR ，然后使用文件/文本差异工具进行差异化.

自我注册 :不建议将自我注册用于COM注册，如下所述: yes :

，在同一列表中启用COM-Interop注册.

.

COM Interop :可以使用 regasm.exe 将.NET程序集注册为COM使用.这几乎与上述设置为 "yes" 的.NET COM Interop设置相同.如果要使用.NET中的COM文件，则需要生成一个Interop程序集文件，然后安装并注册实际的COM文件(您可以执行此操作).两项操作都必须执行.

加入几个链接.这些(古老的)文章涉及 regasm.exe ， tlbexp.exe ， tlbimp.exe 和 gacutil.exe .对您来说不是必需的，但请留作参考:

某些链接 :

I'm migrating a VSTO OUTLOOK add-in from 32-bit to 64-bit. It works well on Office 2007 32-bit. The goal is to make it run on Office 365 64-bit.

I have recompiled the add-in for a 64-bit plateform and updated the installshield project.

When I install the add-in on a new Windows 10 machine using my account (I have admin privilege), it works fine. I can see it in Outlook and I can use it.

However, if I log out and ask someone else to log in on the save machine (this someone else also has admin privilege), the add-in shows up in Outlook but this error is shown when the user uses it:

System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {29AB7A12-B531-450E-8F7A-EA94C2F3C05F} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

Any idea?

Details:

  • This add-in uses only one external DLL: a 64-bit DLL from Redemption.
  • The solution has been compiled in Visual Studio 2015. Platform target: x64.
  • To install it on a computer, I use a MSI that I've created using InstallShield Express on Visual Studio 2015.
  • In InstallShield, I have specified ALLUSERS-1 (Per-machine installation).

  • The DLL is registered using the following code:

    Dim WshShell

    Set WshShell = CreateObject("Wscript.Shell")

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

    Set WshShell = nothing

解决方案

Actual Steps: Just an attempted, pragmatic summary on top: 1: Whilst logged in as the second user, try to launch regedit.exe and export HKCR (maybe HKCU as well), then register the COM dll, export again and diff with a suitable diff tool (if the launching worked at all that is). 2: Download ProcMon.exe and monitor your application / add-in launch to determine what is going on. 3: Use Visual Studio and step-through and checking the Modules view to determine what is going on during launch. 4: Use oleview.exe to see what registration the COM file requires (open embedded typelib). File => View Typelib.... More details below.

Quick Check: Maybe check this first: Outlook Redemption - using RedemptionLoader without regsvr32 the DLL.

Also, did you shut down everything before the second user logged on? Or did you just switch users? Maybe try both, make sure your first login has nothing loaded or locked.

The below "registration debugging" might miss the target. It looks like this could be something more peculiar. Maybe just skim it.

Deployment Mnemonic: Maybe try this deployment mnemonic. A little paragraph with reminders how you can think to try to solve deployment problems: "What is locking, what is blocking, what is missing, etc..."

Registration: Though this looks like a simple missing registration, it could be something more peculiar. I have this application launch check list that you can skim. Not written for add-ins, but might give you some ideas.

  • regsvr32.exe: Did you try to run regsvr32.exe manually as the second user to check if that works? Though it is possible to register a COM file per-user, I don't know of a way to use regsvr32.exe to do so that is reliable.
  • ProcMon.exe: Are you familiar with using ProcMon.exe? Her is a rudimentary example. And Hanselman showing how it is done (YouTube). You can use that to try to determine what is failing and when. Needs some practice to use effectively, but it is my "first and last resort".
  • Visual Studio: I like to use Visual Studio to step through the code and look in different windows (modules for example) to understand how the application works and hence to determine what can be wrong during launching.

  • oleview.exe: To figure out what a COM-file registers during self-registration there are several ways. Launching oleview.exe with admin rights and then going File => View Typelib... and then locating the COM file you want to check and opening gives you the embedded IDL details.

  • RegSpy2.exe: Alternatively you can use RegSpy2.exe for COM registration extraction. See sample here.

  • Capture Compare: Finally a setup capture tool can be used for debugging. It scans the registry (and disk) for before and after changes. In other words you make a baseline, register the dlls and then scan for differences. The reliable tools are expensive (AdminStudio, Advanced Installer Architecht, etc...). The poor man's version of a setup or registration capture is to export HKCR before and after using regedit.exe, and then diffing with a file/text-diff tool.

Self-Registration: Self-registration is not recommended for COM registration as described here: MSI register dll - Self-Registration considered harmful. In Installshield you can simply register a COM file by extracting the COM data at build as illustrated in the image below. You can also enable COM-Interop registration in the same list by setting the flag ".NET COM Interop" to yes:

.

COM Interop: .NET assemblies can be registered for COM use using regasm.exe. That is (almost) the same as the .NET COM Interop setting mentioned above set to "yes". If you want to use a COM file from .NET you need to generate an Interop assembly file and then installing and registering the real COM file (which you do). Both operations must be performed.

Throwing in a couple of links. These (ancient) articles deal with the use of regasm.exe, tlbexp.exe, tlbimp.exe and gacutil.exe. Not needed for you, but leaving in for reference:

Some Links:

这篇关于使用其他帐户连接到计算机时未注册DLL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆