Use DLL in C#

Member_14817640

Hello,

I have a dll created with delphi language (Borland Delphi 7) which thus contains functions in delphi which I would like to use in C# under Visual Studio 2017. It is a native dll.
I want to use for example the GENERATE_FILE function contained in test.dll.

Delphi code :
procedure GENERATE _FILE(Path, Input_File : AnsiString); stdcall;

procedure GENERATE _FILE(Path, Input_File : AnsiString); stdcall;
var

begin
…
GENERATE_CALC(Path_And_File, CRC32, Total, err);
…
end;

In C#, I want to use the function GENERATE_FILE contained in test.dll but what is the type of the parameters Path and Input_File in C# ?

Below is an example of C# code I made to use test.dll in delphi in C#. I set string as a type for parameters of the function GENERATE_FILE.

namespace AppTest
{
Public class Program
{
[DllImport("test.dll", CharSet = CharSet.Ansi)]
public static extern bool CREATE_FILE(string pathDirectory, string filename);

    static void Main(string\[\] args)
    {
        GENERATE\_FILE(@"C:\\Users", "file.txt");
    }
}

}

I added the test.dll in Visual Studio by right clicking on the project then add an existing element, then, in the properties of the test.dll, I put "Content" in Generation action and I put "Always copy "(output directory). When I run the solution, I have the test.dll in bin\Debug.

But when I test this program, I get the following error at the line that contains:
GENERATE_FILE(@"C:\Users", "file.txt");

System.DllNotFoundException: 'Unable to load DLL' test.dll ': The specified module could not be found. (Exception from HRESULT: 0x8007007E) '

How to solve this problem ?
I think the issue is about the type of parameters in the function GENERATE_FILE. What are the type equivalents between delphi and C# for the function GENERATE_FILE ?

Thank you for your help.

Dave Kreskowiak

In C#, you can only use the string type. See Calling a Delphi DLL from a C# .NET application - Stack Overflow[^] and be sure to read the entire thing. There are links you're going to have to follow and read. Depending on what your Delphi code is doing, you may need to rewrite it to support being called from an external caller.

Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak

Luc Pattyn

Quote:

I think the issue is about the type of parameters

Why? the error message was pretty clear, it said

Quote:

'Unable to load DLL test.dll

which may not be entirely accurate, it would better be "unable to load DLL test.dll or some of its dependencies" (that is other DLL's your test.dll might be relying on). Don't worry about your parameter types right now, first make sure you have all the required DLL files are in a location where the .NET executable can find them. Maybe start looking here[^]. BTW: your DLL files will need to have the same 32-bit/64-bit choice your .NET code has. FYI: AFAIK there also is Delphi.NET which would mean you could recompile your Delphi code (assumed available) and use its output as a regular .NET DLL, without any P/Invoke stuff. :)

Luc Pattyn [My Articles] Nil Volentibus Arduum

Lost User

Tested example[^] Should work.

Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.

kalberts

I am planning a different approach - have written half of the code, but it is not ready for testing yet. In my case, it is one subsystem written in C++, others in C#. Rather than messing around with P/invoke and all sorts of parameter transfer, synchronization and whathaveyou, I run it as two processes. The two subsystems have limited, and structurally very simple, data interchange. I find it far easier to exchange those data through a named pipe. The data format is application specific, but as these two subsystems belong to the same application, it is like an internal API with no more need to adhere to a standard than any other internal interface. I like strong isolation between subsystems and modules. It gives greater freedom within each subsystem/module, and it keeps the architecture clean. And it makes the system flexible: If I later want to replace that C++ subsystem with one written in Cobol, say :-), I could do so without any effect on the C# part. Well, if I could access that Cobol code through the same P/invoke interface, it might be similar, but now I don't have to worry about that at all. I am considering the same approach even when the subsystems are all in C#: Threads are fair enough, but do not provide the same isolation as separate processes. When different tasks really are independent (such as one monitoring external equipent/events, the other one interacting with the user; the only common data are the summary reports from the monitor process), they might as well be implemented and run as completely separate entities. Two simple entities are better than one complex.