I have a 32 bit in-proc STA VB6 dll. I sadly cannot do anything about this. My C# component greatly benefits from being 64 bit. Is there anyway to call/interface with this 3
The 32bit COM component will have to run out of process.
Before embarking on creating a wrapper, check out whether COM+ (Object Services) will host it.
There's no direct way you can do this.
Since you can't port the VB6 inproc dll I'd suggest you write a 32bit out of process server that implements the same interfaces and have it delegate down to the VB6 code. Then, your 64bit app can call the out of process server as COM will take care of marshaling the types between the processes.
It ain't pretty, bit it will work!
You can load a (for example) 32-bit only DLL in a surrogate, and access it from a 64-bit process, in the following manner.
This will work provided there is a marshaller available, which there generally will be for a component with a typelib because they usually use the standard marshaller. It will not work if the object requries a custom prox/stub because 64 bit versions won't exist, or you wouldn't have this problem in the first place.
First you need an AppID. If the DLL already has an AppID, you should use that. You can find out by checking under the CLSID key for the CoClass you are interested in.
The example used here is the Capicom.HashedData
and Capicom.EncryptedData
classes. Capicom is 32-bit only.
AppID: CAPICOM does not have an AppID, so for the AppID I have just used the CLSID of the EncryptedData class.
CLSID: You need a list of the CLSID of each class you want to be able to create from 64-bit clients. In this example, it is just EncryptedData and HashedData.
Registration: Create a registry file containing the details, as per the example, and load it into the registry.
You should use the 32-bit version of Regedit to do this, as it is a 32-bit component. If you have a 64-bit component you want to access from 32-bits, use the other one. (This is because of the registry virtualisation for the 32-bit compatibility layer- using the the matching bitness version of regedit takes care of this issue for you, by making sure you edit the correct virtualised version of the registry).
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}"
Save to a myComponent-dllhost.reg
file, and away you go.
c:\windows\sysWow64\regedit.exe "myComponent-dllhost.reg"
You should now be able to access Capicom.HashedData and Capicom.EncryptedData from 64-bit script/COM hosts.
Notes:
"DllSurrogate"
entry. That's it!This article Dealing with Legacy 32-bit Components in 64-bit Windows help you :
I have found this solution, see in article :
• Converting a project type from in-process to out-of-process
• Using COM+ as a host (this work for me)
• Using dllhost as a surrogate host