I posted this originally at the bottom of a thread that is probably
inactive, so I am now
posting it in its own thread. I have a .Net (2.0) assembly that I
want to call using a Com client (a VB6 program) on another machine. I don't
need it to be strong-named or in the GAC - the assembly will be in the same
directory as the Com client.
So, based on various examples from googling, my process has been:
1. Make sure that the assembly [call it MyAssy.dll] has ComVisible
attribute set, and use both an interface and a class that implements the
interface.
2. Make sure that the assembly, the interface and the class are all
decorated with GUID attributes, and the Interface also has a ComVisible =
true attribute.
3. Build the .Net assembly.
4. On the .Net machine, regasm MyAssy.dll /tlb:MyAssy.TLB. This succeeds,
and I copy both the dll and the type library to the VB6 machine with .Net
2.0 framework installed.
5. Again, regasm MyAssy.dll /tlb:MyAssy.TLB (with correct paths everywhere.)
6. Open the VB project and add the reference to the type library. In the VB6
project I can now see the class and Intellisense shows me all its methods.
So far so good.
7. However, when I try to compile, I get Run-time error -2147024894
(800700002) Automation Error - Cannot find the file specified. The error
occurs when
I instantiate an object from MyAssy.dll
The GUIDs in the registry appear to match the GUID for my class and the Type
library. I have numerous times removed references, unregistered, verified
that the GUIDs are gone from the registry, reregistered, and many other
things but have not been able to solve this problem. Even more annoying, I
did a proof-of-concept of this whole process several months ago, and it
worked fine, and continues to work, on the same 2 machines. The difference
here is that MyAssy.dll actually wraps another .Net DLL that actually does
something useful , but even when I temporarily removed the reference to the
useful
.Net DLL from MyAssy.dll, I had the same problem.
Any idea what I am doing wrong?
Thanks much,
\Elizabeth
""Walter Wang [MSFT]"" <wawang@online.microsoft.com> wrote in message
news:Rxi5aHcUIHA.1528@TK2MSFTNGHUB02.phx.gbl...
> When you're not putting the assembly in GAC, if it's also not
> strong-named,
> then it must be placed within the same directory as the COM client that
> uses this assembly via COM interop. Basically we have three types of
> scenario regarding .NET COM server:
>
> * assembly is strong named, installed into GAC; use regasm without switch
> /codebase. Fusion will find the assembly from GAC.
> * assembly is strong named, not installed into GAC; use regasm with switch
> /codebase. Fusion will find the assembly from the location where it's
> registered.
> * assembly is not strong named (cannot be installed into GAC); you cannot
> use regasm with switch /codebase. This time it can only be used by COM
> clients that in the same directory as this assembly.
>
> For .NET Fusion, Richard Grimes has an excellent online workshop:
>
> http://www.grimes.demon.co.uk/workshops/fusionWS.htm
>
> Regards,
> Walter Wang (wawang@online.microsoft.com, remove 'online.')
> Microsoft Online Community Support
>
> ==================================================
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ==================================================
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
Adam - 30 Mar 2008 07:06 GMT
Elizabeth,
Sounds like maybe your COM library is referencing something that can't be
found?
Adam
> I posted this originally at the bottom of a thread that is probably
> inactive, so I am now
[quoted text clipped - 71 lines]
> > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
Econnolly - 30 Mar 2008 16:06 GMT
Actually, I ended up using the /codebase option with the regasm, and it
started working! I got this help in another forum.
This worked even though I hadn't given the DLL a strongname. There is a
warning when I use regasm that if the DLL doesn't have a strongname it could
interfere with others on the computer; for my particular case this is not a
problem as I will always ever use this one version ONLY (and hopefully will
before too long be replacing the entire VB6 app, so this is a temporary
measure. But there are few temporaries in the world of released software....)
Also, as far as I know you need to unregister and reregister the DLL every
time there's a change, even if the interface doesn't change. Again, this is
not a problem in our case; the batch files to register unregister seem to
work very reliably.
Hope this works for others as well.

Signature
E. Connolly
> Elizabeth,
>
[quoted text clipped - 78 lines]
> > > This posting is provided "AS IS" with no warranties, and confers no
> > > rights.