Question

I’m calling a C++ DLL from C# via P/Invoke using DllImport. The DLL is produced by a third party and is x86 only (so our C# code is built as x86 as well).

If I call a certain function on the DLL from a console application, I always get one result which is correct. The function takes a file path and extracts some information from the file.

The signature of the function is:

private static extern int Function(
    string str1,
    int bool1,
    ref uint outUint1,
    ref uint outUint2,
    ref uint outUint3,
    ref double outDouble1,
    ref double outDouble2,
    StringBuilder outStr1);

And the unexpected result is in one of the ref uint parameters.

If I create a unit test and call the exact same code (with all parameters and such hardcoded), I get an entirely different result, which is incorrect. The incorrect result is always the same. I’ve tried both MSTest and NUnit tests using various different runners with the same result.

Cases producing correct results:

• Console app
• Winforms app
• Console app running the code but launched from a Unit Test (NUnit)

Cases producing incorrect results:

• Test run from Resharper Test Runner (NUnit)
• Test run from Visual Studio Test Runner (MSTest)
• Test run from NUnit GUI Test Runner
• Test run from NUnit Console Test Runner

My test environment is Windows 8 and the C# is built for x86 targeting .NET framework 4.

Do any of you have any ideas about what’s causing this issue or what I can do to debug it further?

I will definitely be attempting to contact the third party that created the DLL, but having a good idea about exactly what’s causing this issue would substantially increase the chance of it getting resolved.

Answer 1

It sounds like the “filepath” it is expecting may be relative to the working directory, or the working directory or even the application directory is important to the dll.

That dll may also try to reference other dll’s in its directory, but can’t find them because it was loaded from its own folder instead of the exe running in its directory.

About half way down this page it describes the search order for dll resolution:

1. The directory from which the application loaded.

2. The current directory.

3. The system directory. Use the GetSystemDirectory function to get the
   path of this directory.

4. The 16-bit system directory. There is no function that obtains the
   path of this directory, but it is searched.

5. The Windows directory. Use the GetWindowsDirectory function to get
   the path of this directory.

6. The directories that are listed in the PATH environment variable.
   Note that this does not include the per-application path specified
   by the App Paths registry key. The App Paths key is not used when
   computing the DLL search path.

Hope that helps.

EDIT: Another idea… You could go and write a wrapper for that DLL so that it returns the correct values, and make an interface that works with your unit tester built into your wrapper.