Tyrone,
If you VBA call DLLA, which calls DLLB which calls DLLC (which is not
present on the user's system), Excel cannot mark DLLC as "Missing" because
it knows nothing about it. But the initial call to DLLA will fails (assuming
no error handling to deal with that situation) as DLLC is not loaded.

You can try Dependency Walker (http://www.dependencywalker.com/) to examine
you modules to see what is missing in the hierarchy of calls.

NickHK

"Tyrone" wrote in message
...
I am supporting several users who are using a fairly elaborate system of
Excel VBA code. Some of it is in individual spreadsheets, some more in
add-ins written in-house, some more in third-party add-ins. These
reference
other DLLs written either in-house or purchased from third parties. The
spreadsheets have elaborate vlookups, hlookups etc. that reference each
other, and do calculations based on each other's values.

Such a system is, of course, a maintenance headache. One of the most
cursed
error messages around here is the infamous "Can't find project or
library".

Which project or library can't it find? Where is it being referenced
from?
What cell's formula set off this error? We don't know. A References
dialog
will pop up, but nothing is marked as missing. Without knowing what
reference is missing, the dialog is virtually useless. The most I can do
is
open VBE and try to compile the current project; but if this works (and it
usually does) we're left with nothing.

The only other solution is to manually search thousands of lines of code,
and thousands of formulas in cells.

There's got to be a better way than this. Yes, we shouldn't have built it
this way in the first place, but we did. Even then, can Excel really do
no
better than "Can't find project or library"? Can it not tell us *which*
one
is missing?