Call .NET DLL from Delphi [duplicate] - c#

This question already has answers here:
Call C# dll from Delphi
(3 answers)
Closed 7 years ago.
As my first time as a student employee programming I have to create a DLL in C#.NET which is callable from Delphi.
I've read about this being not so easy due to Delphi being native code and .NET being managed.
I've also read about 'Unmanaged Exports' from Robert Giesecke. Could this be the solution?
Since I do not have Delphi on my machine (Delphi isn't free), I can't test this out for myself.
Also, will I have problems with my datatypes when I implement the Unmanaged Exports?
Last but not least, is there a language I could use that would have the same problem as Delphi for loading the DLL? It'd be nice for me to be able to test.

UnmanagedExports is one option. It certainly works very well. Other options include:
Exposing the functionality using COM.
Exposing the functionality via a C++/CLI mixed mode assembly.
Hosting the CLR from your Delphi code.
The final option is not very tractable. Don't attempt to do that.
You'll almost certainly encounter problems with interop data types unless you are already an expert in the field.
You can certainly test this out with FreePascal. Very likely you can write code in FreePascal that consumes your .net assembly and later use the exact same code in Delphi. Even if you have to change it somewhat, the lessons you will learn will be exactly the same.

You can make your .Net DLL as Com visible. Check this link.
Delphi can load Com objects without problems. This in theory, I don't have specific code samples, but you can try with different tutorials, they practically explains the same.
I don't know about the data types, but COM always tries to cast to a base type (double, float to decimal, number to integer, and complex objects to dynamic objects).

You can use the .Net Runtime Library for Delphi in http://dotnetruntimelibraryfordelphi.sourceforge.net/
The runtime library allows you to host and access .net library types.

Related

Wrapping code from C++ to use in C# [duplicate]

This question already has answers here:
Wrapping C++ for use in C#
(3 answers)
Closed 9 years ago.
I have a C++ project which consists of some headers, cpps, some lib files and DLL files.
I want to wrap these files in order to use them on a C# project.
I wanted to make one DLL which will contain the all C++ project and then to wrap it with C# class so I would be able to work with it.
So my questions are (Working with Visual Studio 2010):
How do I make the final DLL file.
a. I know how to link the lib files to the project, but how do i link the DLLs?
b. What do I need to add to my headers in order that the functions declared in them (which are implemented in the lib files) will be imported to the DLL. (What is __declspec)?
After building the final DLL file, how do I create a C# project which use this DLL file?
Thanks in advance
This is called (COM) InterOp. Fortunately one of the major design goals of the original .NET Framework was to facilitate easy interoperability between managed and unmanaged code. Broadly speaking there are three different kinds of interoperability that one may wish to achieve when dealing with managed code.
Making calls into COM components from managed code
Making calls into native DLLs from managed code. This known as platform invocation or colloquially, PInvoke. (This is what you want)
Allowing COM components to call managed code by wrapping the managed code with a runtime callable wrapper (RCW). This can be used as a strategy for the piecemeal replacement of legacy code on a planned basis.
The process by which data is moved from the managed to unmanaged realm is known as marshalling. This is the name by which data and its associated types are serialised across some boundary or other. To support this process there are a collection of classes that exist under the System.Runtime.InterOp namespace.
Broadly speaking the process is essentially as follows:
Determine function names (I use Dependency Walker)
Determine function signatures (Look it up on MSDN if it's a MSFT one)
Determine data types and structures required by code
Write managed code to call into the native code that satisfies the criteria determined above
Test the wrapper code that's after being written to ensure that it produces the expected results (this can often be the most tedious part)
You are looking for C++/CLI. With this hybrid you can write a dll that can contain any amount of normal C++ code and it can contain managed classes that can use .NET types (like System.String) for it's interface and internally handle your normal C++ types. That dll will be usable from C# like any other .NET dll. From the calling programs perspective will look as if you had written it in C#.
Normally answers should contain practical examples, but C++/CLI is a large field to cover, you could write books just describing your scenario. You can find a good tutorial here and a good Overview here.

Managed Types C++ [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What's the difference between a non-unmanaged type and a managed type?
I was recently working on an application in C++ and I came across something called managed types, native types, marshaling etc. I am not quite sure what these terms mean. From what I have been reading, it seems that we have managed types in c++ to allow access to some .Net features (.Net native types) and we use marshaling to convert from managed types to native types (vice versa). Am I correct? thanks~
Managed C++ was/is a Microsoft creation. Applications developed using the managed C++ framework operate within a virtual-machine environment the same way that .NET applications do. This provides facility such as more run-time checking, memory allocation. Also, the VM provided garbage collection just like .NET does for C#. The limitation with the managed framework is that it the VM did not support multiple inheritance (C# does not support multiple inheritance). Therefore managed C++ development was restricted.
Marshaling is also called serialisation where objects are converted to other "simple" types for transmitting to other processes or machines via RPCs.

Exporting a native C function from a .net DLL? [duplicate]

This question already has answers here:
Is is possible to export functions from a C# DLL like in VS C++?
(4 answers)
Closed 6 years ago.
I have a .net assembly written in C#, and I'm looking to export a native C function from the assembly.
I have an application which will perform a 'LoadLibrary()' on any DLL's found in a 'plugin' folder. After loading the DLL, the application performs a 'GetProcAddress' looking for a function named 'Register'. The application expects this function to follow the C calling convention.
How can I export a function named 'Register' from my .net assembly, so I can successfully hookup with the plugin system for this application?
Thanks,
Andrew
Have a look at Unmanaged Exports.
Write a .Net library in Managed C++ and there you can export a "Native" method/function.
Sadly Microsoft does not support this feature, and you have to change the msil after the build to expose those methods.
It is possible as one guy has shown a reasonable solution
on codeproject or here,
but it requires a post build step and you are on your own after that.
I don't know if this hack will work on .net 4.0 or later though.
Hopefully Microsoft will listen to us and support this simple feature in C# since the CLR support is already there.
What you want is a Reverse P/Invoke. You can't actually embed a C function in a C# dll, if by that you mean a function actually implemented in C, but by following the tutorials given on the linked page you can create a DLL export that's callable by unmanaged C/C++ code.

What is the best way to wrap our software library to serve both C++ and C# client apps?

I am starting work on a new project where the core product is a Software Library. There is existing code we will be wrapping, written in C++ because it is very numerically intensive; we own and compile this core code.
I believe we will have two prominent client types:
1. App written in C++, probably MFC
2. App written in C#.NET.
The Question: In order to offer an "ideal" interface to both these client types, what technology do we use? For example, we could offer two interfaces, one using C/C++ functions and callbacks for the C++ clients, and the other using C#.NET for the C# clients? Also, in principle, could this be done nicely in one DLL, or will we want two (or more)?
Other info... Client apps are embedded, not a desktop or laptop; assume any UI is not Windows-based. Also we will have to compile and test for both 32-bit and 64-bit, probably C++ on 32-bit and C# on 64-bit.
My apologies here -- I realize this question may have been asked and answered previously, but if so, I was not able to find it.
Interesting question, I'm looking forward to other answers.
One possible solution, if probably not the best: If your library code follows object-oriented practices, you could write the core functionality in C++ and then provide separate COM wrapper classes around the core classes (also in C++). This would allow you to use your library components from .NET via COM interop. I don't know how efficient that would be — I suspect performance should generally be fine —, and COM has some obvious drawbacks (no generics, for example), so that may not be the optimal solution.
If your library is not object-oriented, you can still call single functions exported from any DLL in .NET using P/Invoke... if you go down this route, it's likely that you'll end up with a C# wrapper around your C++ DLL.

Reverse PInvoke and create a full unmanaged C# program

I know this is a strange question but the idea is simple: I prefer C# syntax rather than C++:
-Setters and getters directly inside a property
-interfaces
-foreach statement
-possibility to declare an implicit cast operator
other small things...
What I really don't know is if is possible to import a c++ dll (expecially std libraries) in C# if I don't use any namespace (even System)
The idea is just to write a program using everything that you will normally use in C++ (nothing from CLR so), even printf for example
Thanks for any answer
No it is not possible to simply import existing C or C++ files into a C# project. They are very different languages and cannot be mixed at the source level.
The way to mix C# and C++/C applications is at the PInvoke or COM Interop level. This works by duplicating the signatures in C# and allowing the C# compiler to determine the binary layout of the native type in order to marshal between the languages.
There's now something close to this
.NET Native compiles C# to native machine code that performs like C++. You will continue to benefit from the productivity and familiarity of the .NET Framework with the great performance of native code.
It's for Windows Store apps only (desktop apps may come in the future):
Desktop apps are a very important part of our strategy. Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications.
And
apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine
No; this is not directly possible. In particular, C++ templates are not supported by C#.

Categories

Resources