How Do I Reference a COM DLL?

  • Thread starter Thread starter TC
  • Start date Start date
T

TC

I posted this question earlier, but didn't receive a reply, so I'm
going to rephrase it and try again.

I have a VB.NET application which requires a COM DLL. When I add a
reference to the DLL, Visual Studio creates an Interop DLL. That seems
okay. I can compile the application and run it on my development
computer.

When I copy the executable and all the DLLs over to the production
computer, however, the system does not use the COM DLL I put in the
application folder. It uses a different DLL which has a bug and causes
my application to fail.

Why is the system using the wrong DLL? How do I force it to use the
right one?


-TC
 
I posted this question earlier, but didn't receive a reply, so I'm
going to rephrase it and try again.

I have a VB.NET application which requires a COM DLL. When I add a
reference to the DLL, Visual Studio creates an Interop DLL. That seems
okay. I can compile the application and run it on my development
computer.

When I copy the executable and all the DLLs over to the production
computer, however, the system does not use the COM DLL I put in the
application folder. It uses a different DLL which has a bug and causes
my application to fail.

Why is the system using the wrong DLL? How do I force it to use the
right one?

-TC
Click to expand...

Was that DLL located and referenced from windows\system32 folder?
 
Did you register (regsvr32) the com dll? Is this a 3rd party dll? If so,
which version is the later version?
 
Did you register (regsvr32) the com dll?  Is this a 3rd party dll?  Ifso,
which version is the later version?









- Show quoted text -
Click to expand...

Kimiraikkonen and Mike,

Thank you for responding to my post. Here are details:

- Neither DLL is located in windows\system32.

- It is a 3rd party DLL. The buggy version is newer (1.3.4.333) than
the good version (1.3.1.247).

- The buggy version is registered. The good version is not. I'm afraid
to register the good version because I don't know what that will do to
the buggy version. This is the production computer, and other software
may rely on the buggy version.


-TC
 
TC said:
Kimiraikkonen and Mike,

Thank you for responding to my post. Here are details:

- Neither DLL is located in windows\system32.

- It is a 3rd party DLL. The buggy version is newer (1.3.4.333) than
the good version (1.3.1.247).

- The buggy version is registered. The good version is not. I'm afraid
to register the good version because I don't know what that will do to
the buggy version. This is the production computer, and other software
may rely on the buggy version.


-TC
Click to expand...

I think you have a few options. You might try debugging on a development
version with the newer dll. This may be futile as you seem to indicate that
the newer dll is buggy. Another choice is looking up examples of reg-free
com. There are numerous blogs on how to do this. This could help in this
situation.
 
Kimiraikkonen and Mike,

Thank you for responding to my post. Here are details:

- Neither DLL is located in windows\system32.

- It is a 3rd party DLL. The buggy version is newer (1.3.4.333) than
the good version (1.3.1.247).

- The buggy version is registered. The good version is not. I'm afraid
to register the good version because I don't know what that will do to
the buggy version. This is the production computer, and other software
may rely on the buggy version.

-TC
Click to expand...

Another option: If your dll has no dependecy except your app, you can
rename buggy version to something before the installation to force not
to register a unwanted dll. Then leave the correct version and let
your app app is installed the bug-free dll must have registered and
must be in use.
 
Back
Top