COM Interop error on 64 bit

[Guest]

I have a VB6 executable that references a .NET 2.0 dll.
The .NET 2.0 dll project has 'Register for COM Interop' checked. Thus,
compiling the dll will generate the .tlb file. This will allow early binding
to work from VB6.

I copied the VB6 exe and the .NET dll to a 32 bit OS. I copied the tlb file
to system32. When I execute the VB6 exe and call the .NET dll it works fine.

NOW, if I copy the VB6 exe and the .NET dll to a 64 bit OS and execute it, I
get the 'ActiveX cannot create object' error. I tried both, early and late
binding but I keep getting the same error.

If I call the .NET dll from another .NET app on a 64 OS, it works fine.

Is there anything different that I would have to do in order to get the VB6
application to call a .NET dll while running on a 64 bit OS?

 

[Willy Denoyette [MVP]]

|I have a VB6 executable that references a .NET 2.0 dll.
| The .NET 2.0 dll project has 'Register for COM Interop' checked. Thus,
| compiling the dll will generate the .tlb file. This will allow early
binding
| to work from VB6.
|
| I copied the VB6 exe and the .NET dll to a 32 bit OS. I copied the tlb
file
| to system32. When I execute the VB6 exe and call the .NET dll it works
fine.
|
| NOW, if I copy the VB6 exe and the .NET dll to a 64 bit OS and execute it,
I
| get the 'ActiveX cannot create object' error. I tried both, early and
late
| binding but I keep getting the same error.
|
| If I call the .NET dll from another .NET app on a 64 OS, it works fine.
|
| Is there anything different that I would have to do in order to get the
VB6
| application to call a .NET dll while running on a 64 bit OS?
| --
| ANeelima


1) The assembly is not registered on the target system, try running
regasm.exe /codebase /tlb <your.dll> from an elevated administrative prompt,
or better create deployment project in VS for your solution.
2) You should never ever copy private dll's and tlb's to %windir%\System32,
they belong to your private application path.


Willy.

 

[Guest]

I ran regasm and created a .reg file for the .NET dll. I then
double-clicked this file on the 64 bit system. This added the required
registry entries.

But, I am still getting the error.

 

[Willy Denoyette [MVP]]

You have to make sure, this dll is registered in the virtualized registry
(the 32bit one). 32 bit COM clients won't get a chance to create such COM
servers when registered in the 64bit registry.
The only way I see you can make sure it's done correctly is by running
regasm.exe (the 32 bit version) on the target system, or by means of a
set-up program, like mentioned in my previous answer.

Willy.



|I ran regasm and created a .reg file for the .NET dll. I then
| double-clicked this file on the 64 bit system. This added the required
| registry entries.
|
| But, I am still getting the error.
| --
| ANeelima
|
|
| "Willy Denoyette [MVP]" wrote:
|
| >
| > | > |I have a VB6 executable that references a .NET 2.0 dll.
| > | The .NET 2.0 dll project has 'Register for COM Interop' checked.
Thus,
| > | compiling the dll will generate the .tlb file. This will allow early
| > binding
| > | to work from VB6.
| > |
| > | I copied the VB6 exe and the .NET dll to a 32 bit OS. I copied the
tlb
| > file
| > | to system32. When I execute the VB6 exe and call the .NET dll it works
| > fine.
| > |
| > | NOW, if I copy the VB6 exe and the .NET dll to a 64 bit OS and execute
it,
| > I
| > | get the 'ActiveX cannot create object' error. I tried both, early and
| > late
| > | binding but I keep getting the same error.
| > |
| > | If I call the .NET dll from another .NET app on a 64 OS, it works
fine.
| > |
| > | Is there anything different that I would have to do in order to get
the
| > VB6
| > | application to call a .NET dll while running on a 64 bit OS?
| > | --
| > | ANeelima
| >
| >
| > 1) The assembly is not registered on the target system, try running
| > regasm.exe /codebase /tlb <your.dll> from an elevated administrative
prompt,
| > or better create deployment project in VS for your solution.
| > 2) You should never ever copy private dll's and tlb's to
%windir%\System32,
| > they belong to your private application path.
| >
| >
| > Willy.
| >
| >
| >

 

[Guest]

I opened the system registry in the 64 bit OS and found the .NET dll under
WOW6432Node. So, I am assuming that it did get registered in the 32 bit
virtualized registry. Is that correct?

 

[Willy Denoyette [MVP]]

I opened the system registry in the 64 bit OS and found the .NET dll under
WOW6432Node. So, I am assuming that it did get registered in the 32 bit
virtualized registry. Is that correct?

Don't know what WOW6432Node is all about, but I guess you mean that your dll is in the
SysWOW64 folder, right? Well, once again, put your stuff in a private folder, but stay out
of the system folders. Anyway, that doesn't mean your DLL is registered, you just copied the
dll in SysWOW64.
What you should do is:
1. Create a private folder and copy your dll and VB client into this folder.
2. Run a command prompt as administrator.
3. Run "regasm.exe /codebase /tlb <yourcomserver>.dll" from the 32 bit Framework folder
(x:\Windows\Microsoft.NET\Framework), where x is your system drive. Take care NOT to run
regasm.exe from Framework64!, or your dll will get registered as 64 bit (in the
non-virtualized registry).
4. Run your VB6 client.

If you want to inspect wheter your COM server did get registered correctly, start regedit
from SysWow64 (the 32 bit version) and seach HKCR\clsid, it should be there, again don't
start regedit from Run..., this will start regedit.exe from System32.

Willy.
..

 

[Willy Denoyette [MVP]]

|I opened the system registry in the 64 bit OS and found the .NET dll under
| WOW6432Node. So, I am assuming that it did get registered in the 32 bit
| virtualized registry. Is that correct?
|
| --

I see, where you got this WOW6432Node from, it's the redirected HKCR\CLSID
registry node for 32bit registered COM classes. This is indeed an indication
the assembly is registered as 32 bit, but more importantly is the assembly
path, this path is correctly written when applying the /codebase option when
registering, without this option, requires the client and server (COM dll)
to reside in the same folder.

Willy.