我有一个ASP经典应用程序引用一些Visual Basic 6.0 COM对象。 其中一个Visual Basic 6.0 COM对象引用另一个第三方DLL。
第三方DLL需要在Windows Server 2008 R2 x64机器上注册。
我已经find脚本在GAC中注册DLL，而不使用PowerShell进行GACUTIL（参考： http ：//weblogs.asp.net/adweigert/archive/2008/10/31/powershell-install-gac-gacutil-for-owershell 。 aspx ）。
现在我需要注册程序集。 我在本地开发机器（x86）上同时使用了GACUTIL和RegAsm。 但是当我尝试在testing服务器上获取DLL时，我遇到了问题。
第一个问题 ：没有GACUTIL。
也就是说，服务器上没有GACUTIL，我使用上面提到的脚本。
第二个问题 ：RegAsm找不到程序集。
在32位.NET Framework下RegAsm找不到该DLL。 错误报告 ：
RegAsm：错误RA0000：无法findinput程序集“C：\ Windows \ System32 \ xxxxx.dll”或它的某个依赖项。
所以我使用了64位的变种，并工作。
但是当我运行我的应用程序时，我的事件日志中出现错误：
ActiveX组件不能创build对象。
一般来说，这是因为找不到要创build的对象，这意味着托pipe对象的DLL没有正确注册。
所以我现在要做的是找出是否有使用PowerShell RegAsm的替代方法。
这是可能的，那么剧本会是什么？
不确定，但是你的麻烦似乎来自于UAC Virtualisation的副作用（这篇文章也可以帮助你），它存在于Vista中，在这里仍然有效。 现在，文件系统和registry的系统部分现在不受用户访问的限制，但假设旧的（32位）程序继续工作，系统使他们相信他们在这些部分上写入，但实际上他将它们redirect到用户地方。 在你的registry中查看“HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node”。
我最近遇到的一个麻烦就是我的MSI是用一个32位库pipe理程序构build的，所以在64位机器上安装时调用这些库使得UAC虚拟化将我的registry键值安装在Wow6432Node中。 这篇互联网文章帮助我解决了这个问题。 我使用Orca从32位到64位replaceInstallutillib.dll。
RegAsm和GacUtil用于.NET程序集。 对于COM组件（在DLL中），您需要使用regsvr32.exe 。
COM注册是一个与.NET 完全不同的过程， regasm通过在COM代理中包装一个.NET程序集以使其在COM中可用，从而跨越了这个鸿沟 – 这是互操作性的一种可能性。
没有GACUTIL
GacUtil附带.NET SDK，对于非开发者系统，其工作应由安装者完成。
我发现我将.NET DLL放在testing机器上的不正确的文件夹中进行注册。
在Windows 64位操作系统上，您具有System32和SysWOW64文件夹。 我将我的DLL放在System32文件夹中，它应该在SysWOW64文件夹中。
我从RegAsm得到的错误：
RegAsm：错误RA0000：无法findinput程序集“C：\ Windows \ System32 \ xxxxx.dll”或其某个依赖关系
应该让我点击，但我错过了。
基本上32位RegAsm找不到我的DLL，但64位RegAsm可以find我的文件，并通过注册程序集与64位RegAsm我把DLL放到64位范围。 我需要它在一个32位的范围内。
我将DLL表单System32移到SysWOW64，32位RegAsmfind了DLL，并在32位范围内注册了它。
现在我的Visual Basic 6.0 COM对象可以find.NET DLL，而且它没有错误“ActiveX组件不能创build对象”。
尽pipe如此，我还没有find一个图书馆或function，将没有实际使用RegAsm RegAsm同样的工作。
如果有人发现这个神话般的野兽，请回答这个问题。
如果您想在PowerShell中使用regsvr32.exe，请首先使用CMD。 这将在PowerShell中打开一个cmd窗口。 这只是一个我学到的漂亮的技巧，但我相信你已经知道这已经与DLL和Windows COM COM objectCs工作。