Develop Reference

C# based DLL wrapping C based DLL Usage Problem

I have code written in ANSI C that I would like to use in C#. I have compiled the C code into a DLL and created C# wrapper classes to interop with the C code. The point of the wrapper is to simplify a users interaction with the underlying C code.
[DllImport(DLL, CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
private static extern void PrintHelloWorld();
public void PrintHelloWorldC()
{
PrintHelloWorld();
}
Above is a simplified example of what I have done so far. Now, I am trying to create a DLL from the C# wrapper classes I wrote. From here I could give both the DLLs created and someone would be able to interact with the C# based DLL to interact with the underlying C based DLL. Below is what I have done and what problem I am having.
I compile the C code into a DLL in Visual Studio 2019 with my Configuration=Release and Platform=Win32.
I compile my C# classes into a DLL in Visual Studio 2019 with my
Configuration=Release, Platform=Win32, and Platform Target as x86.
I create a new project and link my C# DLL and set Platform Target as x86.
I put my C DLL into the Debug folder of the project so that it is available to the C# DLL through the marshal directive.
I try to make a call into the C# DLL and below are the chain of events occurring.
Program calls C# DLL method PrintHelloWorldC() and is successful
Within PrintHelloWorldC() it tries to make a call to PrintHelloWorld();.
Following Error Occurs:
System.BadImageFormatException
HResult=0x8007000B
Message=An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
My research yielded that it was most likely a mismatch in Platform Target between the DLLs and Test Project, however, I have double checked all the configurations and they should all be compiled for x86.
Below is what additional testing I have done.
Created a C# Project, and wrote simple code to make a call directly into the C based DLL. This works fine.
It seems that as soon as I try to use the two DLLs on top of each other in another project I start facing issues.
Any help or guidance is appreciated. Thanks in advance!

loadlibrary fails with error code 127

I've a very interesting problem. It's sounds very easily, but I didn't finf any information about it.
I've a C# solution with excel Add-in and winforms application and library project with only one method.
project with library have next code:
[DllImport("Kernel32.dll", SetLastError = true, CharSet = CharSet.Ansi)]
public static extern IntPtr LoadLibrary(string filename);
public sealed class LibraryInfo
{
public readonly IntPtr Handle;
public LibraryInfo(string dllName)
{
Handle = LoadLibrary(dllName);
}
}
public LibraryInfo GetLib(string name)
{
return new LibraryInfo(name);
}
Look's like simple.
So I've a call of that method from add-ins and from WinForms
I've a Dll, builded for x64 platform and x86 platform.
And now magic:
LoadLibrary returns error code 127 only when I run it from Add-in and x64 configuration and on excel-2016(x64, ofcourse). When I run it on x86, or winform (both x86 and x64) it works. And it is not all, when I run it on Excel 2013 it's works fine too!!!
mayby somebody knows?

Error code 127 is ERROR_PROC_NOT_FOUND.
The specified procedure could not be found.
Typically that means that something is calling GetProcAddress which is failing because the module in question does not export a function of the specified name.
Exactly where that is happening cannot be discerned from the code that you supplied. Unfortunately you did not supply very much code, and did not supply the code that you are using. That much can be discerned from the fact that you mention an error code in spite of the code in your question performing no error checking.
It could be that code you did not show is calling GetProcAddress and failing. Or it could be that the loader is yielding that error code whilst resolving the dependencies of the library you load.
So, what I've stated above is a broad explanation for the behaviour that you report. Anything more specific would require the actual code in use, but only you have that code.

Problem solved.
I ve a dependent dll for my, called "Chart", so excel 2016 have "chart.dll", 2013 - not.
The solution is rename my "chart.dll" and rebuild both of dlls.

How can a C# program use a C++ dll of any version?

We're creating a dll, written in C++, providing access to some hardware. We also have a C# program that uses this dll.
We're having an issue with the versions. Indeed, when running the C# program, it absolutely wants to use the exact C++ dll version it used when compiling. I.e. if the C# program was compiled using C++ dll 1.2.3.4, then the program will refuse to run with C++ dll 1.2.3.5.
I'd like to instruct the C# program to use any C++ dll with version 1.2.anything.
Where can I configure this in the C# project?
This question has been superseded by that one, more related to COM.

Nothing this fancy exists in C++. Using a side-by-side manifest technically permits this but you would have known about it since you would have typed the version number in the manifest of your C# program.
The far more likely explanation is that you actually created a C++/CLI assembly. Many programmers confuse C++/CLI with C++. Easy mistake since that language permits using native C++ code. But it actually gets compiled to a mixed-mode assembly, an assembly that contains both IL and native code. The normal CLR version checking occurs for such an assembly when the CLR loads it, it is only happy with an exact version match. A strong DLL Hell counter-measure.
And the normal CLR version wrangling option is available to bypass this check, a <bindingRedirect> element in your app.exe.config file. As well as controlling the assembly version number the way you do it for your C# code so this isn't necessary.
The easiest way to check if this guess is accurate is by using Project + Add Reference and select the DLL. If that doesn't draw any complaint and the assembly gets added to the References node of your C# project then you know it is a normal .NET assembly. Don't forget to take advantage of that, no pinvoke required.

Load the dll at runtime and use reflection to call it's methods.
Assembly assembly = Assembly.LoadFrom("C:\\test.dll");
Assembly.GetTypes();
Activator.CreateInstance(type);

I don't think it is possible to configure your program to use 1.2.* version and no others. Unless you would write the code for that on your own. Another possibility would be not to change the version tag of the C++ dll, but it does not seem you want to that.
A solution avoiding the version dependency would be the usage of dllimport. You can load any dll written in C++ with it. It is free of version dependency. See the example from the msdn and link at the end:
using System;
using System.Runtime.InteropServices;
class Example
{
// Use DllImport to import the Win32 MessageBox function.
[DllImport("user32.dll", CharSet = CharSet.Unicode)]
public static extern int MessageBox(IntPtr hWnd, String text, String caption, uint type);
static void Main()
{
// Call the MessageBox function using platform invoke.
MessageBox(new IntPtr(0), "Hello World!", "Hello Dialog", 0);
}
}
Description in MSDN

How to use a C++ dll in Unity3D?

I am aware of this similar question, but it does not respond to my problem.
I have written two .dlls using Visual Studio 2010. One is in C++, and communicates with an SDK that was written in C++. The other is a C# wrapper for that C++ library, so that it can be used in C# contexts.
My plan was that this would let me use my code in Unity3D, but apparently that is not the case. It seems like Unity3D does not allow me to import .dlls as Assets if they are not a .NET assembly. So I can add my C# wrapper, but not the C++ dll.
This results in a DllNotFoundException whenever I try to access the C++ library. I have tried simply copying the C++ library into the Assets/Plugins folder, but that gives the same results.
Is there a way to do this properly? This is a very vital part of my project setup.

The problem is that the DLL is not being found when the p/invoke runtime code calls LoadLibrary(YourNativeDllName).
You could resolve this by making sure that your DLL is on the DLL search path at the point where the first p/invoke call to it is made. For example by calling SetDllDirectory.
The solution that I personally prefer is for your managed code to p/invoke a call to LoadLibrary passing the full absolute path to the native DLL. That way when the subsequent p/invoke induced call to LoadLibrary(YourNativeDllName) is make, your native DLL is already in the process and so will be used.
internal static class NativeMethods
{
[DllImport("kernel32", SetLastError = true, CharSet = CharSet.Unicode)]
internal static extern IntPtr LoadLibrary(
string lpFileName
);
}
And then somewhere in your code:
private static IntPtr lib;
....
public static void LoadNativeDll(string FileName)
{
if (lib != IntPtr.Zero)
{
return;
}
lib = NativeMethods.LoadLibrary(FileName);
if (lib == IntPtr.Zero)
{
throw new Win32Exception();
}
}
Just make sure that you call LoadNativeDll passing the full path to the native library, before you call any of the p/invokes to that native library.

Note that the DllNotFoundException can be caused by building your Unity DLL in Debug instead of Release!
A simple oversight that can cause a headache.

This also happens when Unity can find your DLL, but is not able to find it's dependencies. Obvious fix is to place dependency DLLs into /Plugins as well, or link your dependencies statically.
Less obvious reason is when your DLL depends on Visual Studio runtime library dynamically, i.e. is built with Properties -> C/C++ -> Code Generation -> /MD option. Change it to /MT to link with runtime statically.

Borland Builder 2006 DLL used in C# .Net - System.StackOverflowException

I have a old DLL (Borland Builder 2006 C++) which I want to use in .Net C# Visual Studio 2010. When I try to import the functions in VS always I get a StackOverflowException from Visual Studio. I've already read a lot stuff and the import seems to be easy. But I fail and don't see my error.
In the Borland DLL the Functions are exported as:
__declspec(dllexport) void TestFunc1() or
extern "C" __declspec(dllexport) void __stdcall TestFunc2()
The decorated names are (*.DEF file created with impdef and proved with dependency walker):
#TestFunc1$qqsv
TestFunc2
In Visual Studio I import in this way:
[DllImport("MyDllName.dll", EntryPoint = "#TestFunc1$qqsv", CallingConvention = System.Runtime.InteropServices.CallingConvention.StdCall, CharSet = CharSet.Auto, SetLastError = true)]
public static extern void TestFunc1();
[DllImport("MyDllName.dll",CallingConvention = System.Runtime.InteropServices.CallingConvention.StdCall, CharSet = CharSet.Auto, SetLastError = true)]
public static extern void TestFunc2();
In booth cases a get a StackOverflowException from Visual studio, when I call:
MyImport_Unmanaged.TestFunc1() or
MyImport_Unmanaged.TestFunc2()
What is wrong ? Can anybody help me ?
Interesting when I import a old dll created with Visual Studio C++ the decorated name of the function is: _TestFunc1#0. The name is quite different to the Borland names but is works.

the correct syntax is:
extern "C" void __stdcall __declspec(dllexport) TestFunc1()

I had the same problem. After a lot of experiments I realized that the problem was not a syntax one. It was the fact that the C++ Builder DLL was using VCL Forms. I removed the forms and everything worked.

Yes, Panos seems to be right. I tried to P/Invoke an old BCB5 DLL with VCL and at the
first look it worked quite OK. But it silently has corrupted the C# program which manifests in strange exceptions a little bit later.
Not using the VCL in the Borland DLL was the only way to get it work. For us this means we have to convert our code to VisualStuidio which is on out todo-list anyway.