Question

I’m working with an external DLL to consume an OCR device using a wrapper written by me. I have made tests on the wrapper and it works perfectly. But, when I use a WinForms project to consume the client class of the wrapper (located an another project), an error arises when calling C# methods imported from the DLL (using [DLLImport(...)]) saying that the DLL is not registered.

The error says:

“DLL Library function no found. Check registry install path.”

All executions have been made in debug mode.
I’ve compared both projects configuration. The most relevant difference is that Test project is oriented to Any CPU and WinForms app only points to x86.

What could it be?

Updates

1. I’ve tried to register the dll using Regsvr32.exe but it didn’t work. I thought about using Gacutil.exe but it required to uninstall all frameworks beyond .net framework 1.1…
2. I was wondering… at testing environment probably everything works well because testing framework has its dll’s or executable files (or something like that) totally registered in windows, so those are trusted dlls. It is possible that debug generated dlls are not trusted by windows and therefore this problem arises?
3. I’ve created a form in the same troubling project and then I call the OCRWrapper from a button I’ve added to it. The OCR’s worked!!. Unfortunately, it is difficult to rewrite the first form because we have invested a lot of hours in it; so, I’m still wondering what do I need to change in the troubling form…
4. I started again the form’s development from scratch and added all the components related to it; everything worked well, the OCR read succesfully all data. When I loaded a combo box using a call to an ObjectContext and the error appeared again… I’m using an entity framework connected to Oracle.

Answer 1

I have a theory.

Let’s imagine the following situation:

• The ocr.dll depends on some other native DLL, lets call it other.dll [A].
  • In case this is a static dependency, you’ll see it through Dependency Walker.
  • If its dynamic, you can use Sysinternals Process Explorer to monitor DLL loading in your working test project at run-time.
• Your ADO.NET provider uses native DLLs under the hood (this is certainly true for ODP.NET) which depend on other.dll [B], which happens to have the same name but is actually a different DLL (or at least a different version) compared to other.dll [A].

Then, in run-time, this might happen:

• When you connect to the database, ADO.NET provider dynamically loads its native DLLs, including the other.dll [B].
• Then you try to call a function from OCR DLL. The P/Invoke tries to load the OCR DLL dynamically and succeeds, but the other.dll [B] is already loaded and ocr.dll tries to use some function from it, instead from other.dll [A] where it actually exists.

Welcome to DLL hell. So what can you do?

• Try varying the order of calls to ocr.dll and ADO.NET provider to see anything changes. If you are (very) lucky, other.dll [A] might actually be a newer version that is still backward-compatible with other.dll [B] and things migh magically start to work.
• Try another version of ADO.NET provider.
• Try another ADO.NET provider.
• Try getting a statically-linked ocr.dll from your vendor (i.e. no run-time dependency on other.dll [A]).