COM Interop Deploy issue

[krissy_kernan]

I am getting the following error when I try to run my code on the
deployed server: "File or assembly name dllname.dll or one of its
dependencies was not found." It is a VB6 app. that calls a .Net dll.
(The .Net code also calls VB6 dlls, but I don't have a problem
executing that part of the code). I ran regasm on the server, but I
continue to get the error when I try to access the .Net code. My
assembly is not strong-named or registered in the GAC, since from what
I read, it didn't sound like it was necessary. I checked the registry
entries on the source and target server for the .tlb file entries, and
they both match. Would there be security settings on the target server
that could be preventing me from accessing the .Net dll? I would
appreciate any help since I am out of ideas. Thanks!

 

[Jeff Brown]

Does your .NET DLL reference any other DLLs, besides those in the GAC?

If so, you may need to copy those other DLLs (and whatever DLLs they
reference, etc.) into the same directory as your VB6 executable and .NET
DLL.

 

[KK]

Thanks for the quick reply.

Yes, my .Net DLL references other VB6 DLLs, but they are all located in
the directory with my VB6 executable.

Thanks, Krissy

 

[learner]

what is the error message?

Could it be your name space ?

I did not exec .net code from vb but I tried exec some dotnet COM class dll
form vbscript. I had to use
"namepaceName.someclass" to create the obj for accessing the dll.

At one time, I got that wrong and I got the message of something not found

 

[Phil Wilson]

It's not just the file name that matters, it's the version too (strong name
would matter if you used it). A common problem is to build the .NET assembly
with an assemblyversion with a * in it, so it gets a new version every time
it's compiled, and that may no longer match what you deployed. Take a look
at the registry entries relating to the classid (not the tlb) of your
assembly class, and if you didn't specify one, that's something else that
may change if you change your assembly. Client programs still use
HKCR\CLSID\{guid} entries with extra data for the version of your assembly -
make sure it matches the one that's installed.