Issue with VB6 using a .NET DLL on one PC with Windows 2000 Server

  • Thread starter Thread starter partybob99
  • Start date Start date
P

partybob99

Hi everyone.

I have a very strange problem and I have no idea how to correct it.

I created a VB.NET DLL that is used by several different apps for
password file encryption/decryption. I have the original .NET DLL and
I also built the DLL with a COM wrapper (the COM interop box checked in
the project...) so it can be used with VB6 apps (or any other language
for that matter). In order for a VB6 app to use this DLL, this control
must be registered on the local operating system using REGASM.

The user has an icon that points to the vb6 app on a mapped network
drive. When the application starts, the app will access the .NET DLL
(packaged in the COM wrapper) locally on the operating system. It does
NOT try to look the the local path of the .exe to access the DLL as
this is not how vb6 works when accessing DLLs.

This approach works great on 2300 + machines with no issues.

Recently we added a VB.NET application that uses this same DLL.
However, in this case, the DLL is stored in the same folder as the
VB.NET application along with the VB6 app decribed above. For 2300
machines this approach also works great. However, we have one machine,
running Windows 2000 server that is causing problems. If we copy the
VB6 application on the network locally to the server's C: drive, it
will start up prefectly. However, if we try to run the application
from an icon to the mapped network drive, the app comes back with a
"ERROR 430 " "Class does not support Automation or does not support
expected interface". BUT, if i rename or remove the vb.NET DLL that is
in the same path as the VB6 application we are trying to run, it starts
up and works great.

It appears that, for one reason or another, the VB6 application is
trying to open the vb.net DLL that is located in the same folder
instead of loading the DLL registered with the local operating system.
However, this condition occurs on only ONE server. With all other PCs,
the vb6 app can be started from the network drive, the DLL is started
normally and it does not matter if the VB.NET is in the same path as
the vb6 app or not.

I have never seen anything like this before. Any help would be
appreciated.

Thanks in advance.
 
Hello Bob ( ?)

The Location of a COM capable automation object is stored in the registry
by Class ID , the easies way to solve this problem is by unregestring the
dll and then reregister it the problem should then be solved

REGASM has an unregister switch REGASM /u MyAssembly.dll

Regards

Michel Posseth [MCP]
 
Hi, thanks for responding.. I already tried this. And after I ran
REGASM with /unregister, I noticed there were still a few registry
entries left over so I did a manual lookup of the DLL in the registry
and deleted every key that referred to the DLL as well. That way I
know the system is clean. And I've done the same procedure before on
my own machine so I know it works.

The vb6 works great as long as the dll is not in the same path.. when
it's there, it bombs with error 430. all other pcs in the enterprise
(over 2300) have reported no problems when the .net dll is in the same
path as the vb6 app.

Yes, I'm literally scoured every source I could think of and i've never
seen anything like this. I think it has to do with security somehow
with the server but I have no idea as to what it could be however.
 
If you have 2300 machines working with no problem, and 1 with problems,
I would suggest that the problem is with the installation or hardware of
this machine.

Reinstall / replace this computer and don't wast any more time on this.


Hi, thanks for responding.. I already tried this. And after I ran
REGASM with /unregister, I noticed there were still a few registry
entries left over so I did a manual lookup of the DLL in the registry
and deleted every key that referred to the DLL as well. That way I
know the system is clean. And I've done the same procedure before on
my own machine so I know it works.

The vb6 works great as long as the dll is not in the same path.. when
it's there, it bombs with error 430. all other pcs in the enterprise
(over 2300) have reported no problems when the .net dll is in the same
path as the vb6 app.

Yes, I'm literally scoured every source I could think of and i've never
seen anything like this. I think it has to do with security somehow
with the server but I have no idea as to what it could be however.


M. Posseth said:
Hello Bob ( ?)

The Location of a COM capable automation object is stored in the registry
by Class ID , the easies way to solve this problem is by unregestring the
dll and then reregister it the problem should then be solved

REGASM has an unregister switch REGASM /u MyAssembly.dll

Regards

Michel Posseth [MCP]
Click to expand...
Click to expand...
 
Back
Top