64 Bit C# with a 32 Bit Vb6 Com Object

64 bit C# with a 32 bit VB6 COM object

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!

Using 64-bit out of process COM DLL from 32-bit Windows Serivce

The dependencies of MathClass.dll was missed in the path. Now I have added the directory path (where all the dependencies are available) to PATH variable, it started working. I am not sure why this issue didn't come for console application.

There is some inconsistency if I create a dll in C# on win 7 64bit and then want to use on WinXP 32bit?

Finally I could solve my problem. The steps that I had to follow were:

• In the command line with NET Tools in WinXP-32bits:

  1. Compile NET Module. csc /target:module test.cs
  2. Generate the key. sn -k myDLL.snk
  3. Attach the key with the module. al /out:myDLL.dll myDLL.netmodule /keyfile:myDLL.snk
  4. Add into the GAC my DLL. gacutil /i myDLL.dll
  5. Register my DLL. regasm /codebase /tlb:myDLL.tlb myDLL.dll

• In VB6:

  1. Create a new standar exe.
  2. Add reference in Project -> References -> Search -> myDLL.dll

  3. Use a next code:

     Dim tst As myDLL.test
Set tst = New myDLL.test
tst.sayHello

And that's all my friends! I took a long time but here I share with you! Thank you!

64-bit managed process: out-of-proc 32-bit COM server non-default interfaces not available

The solution was to use type library marshaling (also known as universal marshaling), using the system-provided marshaling engine in oleaut32.dll. The universal marshaler can be used with any custom interface, provided that the parameters are variant-compatible.

To use the universal marshaler for an interface, the interface is tagged with oleautomation, as in this sample interface:

[
    object,
    oleautomation, 
    uuid(23D4EC0B-96DA-4D18-82BD-40E3AA0483FD),
    version(1.0),
    dual,
    helpstring("Description of ICustomInterface1"),
    pointer_default(unique)
]
interface ICustomInterface1 : IDispatch
{
    // Methods and properties …
}

Universal marshaling also requires the following Registry entries:

• HKCR\TypeLib<type library GUID><type library version>

• HKCR\TypeLib<type library GUID><type library version>\0

• HKCR\TypeLib<type library GUID><type library version>\0\win32 = “path to type library file”

• HKCR\TypeLib<type library GUID><type library version>\Flags

• HKCR\TypeLib<type library GUID><type library version>\HelpDir = “path to help folder”

• [HKEY_CLASSES_ROOT\Interface<interface GUID> @="Interface name"

• [HKEY_CLASSES_ROOT\Interface<interface GUID>\ProxyStubClsid32
  ="{00020424-0000-0000-C000-000000000046}"

• HKCR\Interface<interface GUID\TypeLib = type library GUID

With this type information, the universal marshaler creates a proxy-stub at runtime, eliminating the need for a custom proxy-stub DLL.

In our case, given that the components were ATL-based, the Registry entries were created automatically once the interfaces were tagged with ‘oleautomation’ and the components rebuilt. For non-ATL projects, this can be done programmatically with the Win32 API’s LoadTypeEx() (which I haven't tried).

Once this was done, non-default interfaces of our ATL-based components became available out-of-process to our migrated-to-VB.NET Excel COM add-in.

All this is detailed in Chapter 5 of "Developer's Workshop to COM and ATL 3.0."

---

Related Topics