Have you checked for multiple versions of the DLL present on the system?
The original developer's system might be finding a different version of the DLL that does have the entry point. Or, there's a bad version of the DLL on your system that the OS is loading despite your building a "good" version.
It can be perverse trying to ensure the OS finds the specific DLL you want, since the DLL searchpath (the "LoadLibraryEx" function, essentially) varies by OS. One way to be certain is to put the DLL in the same folder as the executable, as all of the search paths implemented by Microsoft include the executable folder as the first place to look. I've been burned many times thinking I'm debugging the DLL I just built, only to find that the OS is loading and using an older version it's finding somewhere on the system.
I am in the habit of simply deleting every copy of a DLL I'm debugging to ensure the OS loads the version I've just built. Using the versioning (DLLGetVersion) helps at runtime, but only if you implement the DLLGetVersion method in your DLL, which isn't necessary to make a DLL work but it helps you do a dynamic (i.e. runtime) check of the version. At app startup I always call DLLGetVersion on the DLL's I've created so as to log the version used. It can be a trick to implement the DLLGetVersion method the way Microsoft says but it can be done, I have code for this if you like. If you do this, then you can increment the DLL's build number each time and differentiate your DLL from build to build. CVI will autoincrement the build for you if you tell it to.
Also, if you have the DLL project in the same workspace as the application that's calling it, CVI won't automatically switch the DLL export library and the DLL from debug to release for you when you switch the executable.
from release to debug and visa versa (assuming you've done a debug and release version of the DLL). This is another way to get fooled - you've built a debug version of the DLL but the app is still binding to an older, release version.
