具有32位VB6 COM对象的64位C＃
我有一个32位进程内STA VB6 DLL。 我遗憾地对此无能为力。 我的C＃组件从64位大大受益。 无论如何从我的64位进程调用/接口这个32位dll？ 任何类型的包装或任何东西？
没有直接的方法可以做到这一点。
由于您无法移植VB6 inproc dll，我建议您编写一个32位进程外服务器，该服务器实现相同的接口并将其委托给VB6代码。 然后，您的64位应用程序可以调用进程外服务器，因为COM将负责编组进程之间的类型。
它不漂亮，有点可行！
本文处理64位Windows中的旧版32位组件可帮助您：
我找到了这个解决方案，参见文章 ：
•将项目类型从进程内转换为进程外
•使用COM +作为主机（这项工作对我来说）
•使用dllhost作为代理主机
您可以在代理中加载（例如）仅32位DLL，并以下列方式从64位进程访问它。
如果有可用的编组器，这将有效，通常用于具有类型库的组件，因为它们通常使用标准编组器。 如果对象需要自定义代理/存根，它将无效，因为64位版本将不存在，或者您首先不会遇到此问题。
如何从64位客户端注册第三方32位组件
首先，您需要一个AppID。 如果DLL已经有AppID，您应该使用它。 您可以通过CLSID键检查您感兴趣的CoClass。
这里使用的示例是Capicom.HashedData和Capicom.EncryptedData类。 Capicom只有32位。
-
AppID： CAPICOM没有AppID，因此对于AppID我刚刚使用了EncryptedData类的CLSID。
-
CLSID：您需要一个希望能够从64位客户端创建的每个类的CLSID列表。 在此示例中，它只是EncryptedData和HashedData。
-
注册：根据示例创建包含详细信息的注册表文件，并将其加载到注册表中。
您应该使用32位版本的Regedit来执行此操作，因为它是一个32位组件。 如果您要从32位访问64位组件，请使用另一个。 （这是因为32位兼容层的注册表虚拟化 – 使用匹配的bitness版本的regedit为您解决此问题，确保您编辑正确的注册表虚拟化版本）。
Windows Registry Editor Version 5.00 ;;; Capicom AppID - just using the Capicom.EncryptedData CLSID ;;; Use default surrogate = empty string [HKEY_CLASSES_ROOT\AppID\{A440BD76-CFE1-4D46-AB1F-15F238437A3D}] "DllSurrogate"="" ;;; Capicom.EncryptedData [HKEY_CLASSES_ROOT\CLSID\{A440BD76-CFE1-4D46-AB1F-15F238437A3D}] AppID="{A440BD76-CFE1-4D46-AB1F-15F238437A3D}" ;;; Capicom.HashedData - use same AppID for all!!!!! [HKEY_CLASSES_ROOT\CLSID\{CE32ABF6-475D-41F6-BF82-D27F03E3D38B}] AppID="{A440BD76-CFE1-4D46-AB1F-15F238437A3D}"
保存到myComponent-dllhost.reg文件，然后离开。
c:\windows\sysWow64\regedit.exe "myComponent-dllhost.reg"
您现在应该能够从64位脚本/ COM主机访问Capicom.HashedData和Capicom.EncryptedData。
笔记：
- 这仅适用于基本的OLE自动化类型。 任何与VBScript或JavaScript中的Windows Scripting Host脚本兼容的对象都应该没问题。
- 您只需将AppID添加到可直接创建的对象。 这基本上是那些带有InprocServer32条目的。 从工厂生成的对象或仅作为子对象可用的对象不必添加AppID。
- 如果已经存在AppID，则需要添加空字符串
"DllSurrogate"条目。 而已！ - 这不会影响DLL的普通客户端。 只要bit-ness匹配，它们将继续像以前一样在进程中加载。 它唯一的区别是它可以从不同位的客户端进行实例化。
32位COM组件将不得不用完。
在着手创建包装器之前，请检查COM +（对象服务）是否将托管它。