我有一个ASP 经典应用程序引用了一些Visual Basic 6.0COM 对象。其中一个 Visual Basic 6.0 COM 对象引用另一个第三方 DLL。
第三方 DLL 需要在 Windows Server 2008 R2 x64 计算机上注册。
我找到了使用 PowerShell 在 GAC 中注册 DLL 的脚本，无需 GACUTIL（参考：http://weblogs.asp.net/adweigert/archive/2008/10/31/powershell-install-gac-gacutil-for-powershell.aspx）。
现在我需要注册程序集。我已经在本地开发机器 (x86) 上顺利使用了 GACUTIL 和 RegAsm。但是当我尝试在测试服务器上获取 DLL 时，我遇到了问题。
首要问题：没有 GACUTIL。
也就是说，服务器上没有 GACUTIL，我使用上面提到的脚本解决了这个问题。
第二期：RegAsm 找不到程序集。
32位.NET Framework下的RegAsm找不到DLL。 已报告错误：
RegAsm：错误 RA0000：无法找到输入程序集“C:\Windows\System32\xxxxx.dll”或它的某一个依赖项。
因此我使用了 64 位版本，并且成功了。
但是当我运行我的应用程序时，我的事件日志中出现错误：
ActiveX 组件无法创建对象。
一般来说，发生这种情况是因为它找不到要创建的对象，这意味着托管该对象的 DLL 未正确注册。
因此，我现在想做的是找出使用 PowerShell 的 RegAsm 的替代方法。
这可能吗？什么样的脚本才能正确执行？
答案1
不确定，但您的问题似乎来自 UAC 虚拟化的副作用（本文也可以提供帮助），它从 Vista 开始就存在，并且在这里仍然有效。一个抽象概念是，文件系统和注册表的系统部分现在受到保护，无法被用户访问，但假设旧的（32 位）程序继续运行，系统会让它们相信它们在这些部分上写入，但实际上它们会将它们重定向到用户的位置。查看注册表中的“HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node”。
我最近遇到的一个麻烦是，我的 MSI 是用 32 位库构建的，因此在 64 位机器上安装时调用这些库会导致 UAC 虚拟化在 Wow6432Node 中安装我的注册表项。这篇互联网文章帮助我解决了这个问题。我使用 Orca 将 Installutillib.dll 从 32 位替换为 64 位。
答案2
RegAsm和GacUtil用于 .NET 程序集。对于 COM 组件（在 dll 中），您需要使用regsvr32.exe。
COM 注册是完全地与 .NET 不同的过程，并regasm通过将 .NET 程序集包装在 COM 代理中以使其在 COM 中可用来弥补差距——这是互操作的可能性之一。
禁止使用
GacUtil附带.NET SDK，对于非开发人员系统，其工作应该由安装程序完成。
答案3
我发现我将.NET DLL 放在了测试机上的错误文件夹中进行注册。
在 Windows 64 位操作系统上，您有 System32 和 SysWOW64 文件夹。我将我的 DLL 放在 System32 文件夹中，而它应该放在 SysWOW64 文件夹中。
我从 RegAsm 收到的错误：
RegAsm：错误 RA0000：无法找到输入程序集“C:\Windows\System32\xxxxx.dll”或其依赖项之一
应该让我点击，但我错过了。
基本上，32 位 RegAsm 找不到我的 DLL，但 64 位 RegAsm 可以找到我的文件，通过使用 64 位 RegAsm 注册程序集，我将 DLL 放入了 64 位范围。我需要它处于 32 位范围内。
我将 DLL 从 System32 移到 SysWOW64，32 位 RegAsm 找到了该 DLL 并在 32 位范围内对其进行了注册。
现在我的 Visual Basic 6.0 COM 对象可以找到 .NET DLL，并且它可以正常工作，不会出现“ActiveX 组件无法创建对象”的错误。
尽管如此，我还没有找到一个可以完成与 RegAsm 相同的工作的库或函数，而无需实际使用 RegAsm。
如果有人发现这种神兽，请回答这个问题。
答案4
如果您想在 PowerShell 中使用 regsvr32.exe，请先使用 CMD。这将在 PowerShell 中打开一个 cmd 窗口。这只是我学到的一个巧妙的技巧，但我相信您已经知道它如何与 Windows 的 DLL 和 COM 对象一起使用。