Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 344
  • Last Modified:

Trouble registering some DLLs we created

My company has produced a couple of DLLs written in Visual C++ - for use within some MS Access databases.

These DLLs are turning out to be quite temperamental when it comes to installing them on target PCs.

I am using Windows XP and one of our customers is using Windows Server 2000 - and we are both having the following trouble:

1.  Place the DLLs and installation batch file in the same directory.
2.  Navigate to this directory using the DOS prompt.
3.  Execute batch file.

The following error occurs:

"LoadLibrary("scinder.dll") failed - The specified module could not be found"

A simple 'Dir *.dll' confirms that 'scinder.dll' is in the directory.

The content of the install.bat is as follows:

@echo off

REM Installation for the scinder.dll and scoutdy.dll files
REM Windows 98/ME/XP/2003 server

path=%path%;%windir%\system;%windir%\system32

echo About to install scinder.dll and scoutdy.dll. You will receive individual message confirmation of each install.
pause
regsvr32 scinder.dll
regsvr32 scoutdy.dll
echo Installation complete.


Have we missed something when compiling these DLLs?  I have heard also of 'self-registering' DLLs - is there a way that we can simply place the DLLs in a customer's System32 directory and have them working without having to execute regsvr32?
0
gawilson2000
Asked:
gawilson2000
  • 2
  • 2
2 Solutions
 
jkrCommented:
Try the dependency walker (www.dependencywalker.com) on the target machine to see whether any other DLL yours might rely on is missing. This is most likely to be the case.
0
 
gawilson2000Author Commented:
I have on my system an application called 'depends' - and after someone else's suggestion I ran it and found out that I was missing an important visual C DLL.

The strange thing was that I was able to place this DLL into System32 and it worked immediately.  So, getting back to the second part of me question, why is it that this one doesn't need regsvr32 - but the DLLs we created do?
0
 
jkrCommented:
That was actually what I was referring to - a missing DLL on the target system. Why did you need nomeone else's suggestion? :o)
0
 
gawilson2000Author Commented:
I wouldn't have - but I received their suggestion before yours.
0
 
_ys_Commented:
> I have heard also of 'self-registering' DLLs
Not only have you heard of them but you've likely created them as well. Self-registering DLLs simply refers to the notion that the DLLs contain their registration code in-situ. They know how to register themselves - you simply ask them to do so; and the easiest way to ask them is to use regsvr32.

> is there a way that we can simply place the DLLs in a customer's System32 directory and have them working without having to execute regsvr32?
It depends on how you use them. If from Access you use CreateObject to create your objects and invoke methods then you'll typically have to register the DLLs. On the other hand if you use DllImport to invoke method then no, you typically don't have to register your DLLs (dependent on how your DLLs are coded internally).

> why is it that this one doesn't need regsvr32 - but the DLLs we created do?
You're toying with two flavours of DLLs.
1) API and
2) COM/ActiveX

DLLs coded as APIs typically don't need registering.
DLLs coded as COM/ActiveX typically do need registering.
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now