In C++,

extern "C"
{
    __declspec(dllexport) int test(char* data);
}
__declspec(dllexport) int test(char* data)
{
    string str = "wassup";
    strcpy(data, str.c_str());
    return 1;
}

In C#

[DllImport(dll, CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
static extern int test(StringBuilder faceData);

static public void testDll()
{
    try
    {
        StringBuilder ASMData = new StringBuilder(500);
        test(ASMData);
        Console.WriteLine(ASMData);
    }
    catch (Exception e)
    {
        Console.WriteLine(e);
    }   
}

I have been doing this kind of job so many times and I have working dll's in my folder but the problem I currently have is really weird. I think it might be a bug of C# or Windows.

As you can see the code above, it is very simple, easy and straightforward. C# should print "wassup" on the console.
But this is how it works:

1st run => works fine.
2nd run with same built objects (no change in code) => works fine.
3rd run with newly built objects (rebuil without any code change) => Unable to find an entry point named 'test' in dll
copy new dll
4th run with previously built objects => works fine.

Once the program is run, I think dll file is stuck in the memory even though the program is terminated.

What do you guys think and what should I do to fix it?

Dani AI

Generated

"Unable to find an entry point" means the runtime found the DLL but could not find a matching exported symbol. Two common culprits are a stale/copy of the DLL being loaded and a name mismatch due to decoration or charset. Given your follow-up about an old DLL being copied, also verify you control which file is actually loaded.

Quick checks and fixes:

  • Verify the exact exported name after each rebuild. On x86, calling conventions can decorate names (e.g., _test, test@4). Run:

    dumpbin /exports your.dll

    If you see _test or similar, either change the native export (e.g., use a .def file) or specify the exact name in P/Invoke with EntryPoint and ExactSpelling = true. See DllImportAttribute docs.

  • Ensure the intended DLL is loaded. Place it next to the EXE, or set the search path early with SetDllDirectory/AddDllDirectory. You can confirm the loaded path with Sysinternals Process Explorer. Windows’ search order is documented here: DLL search order.

  • In Visual Studio, check for stale copies: project/item "Copy to Output Directory", post-build events, or msbuild targets that copy an older DLL into bin. A Clean/Rebuild may reintroduce it.

  • Safety: avoid buffer overruns by having the native function accept a buffer pointer and its capacity, and use a bounds-checked copy. Also match bitness (x86 vs x64); mismatches usually throw BadImageFormatException, but avoiding them simplifies troubleshooting.

Recommended Answers

All 3 Replies

Bump

Did you check that the file still exists in the output folder of your build? Visual Studio could be deleting the DLL because you're doing a rebuild. (Performs a 'Clean' step)

Dayum.. it was really stupid of me. Thd old dll that was included in the solution kept being copied into bin folder. Thanks for the advice!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.