Create a C# DLL That Can Be Imported in a Delphi App Using stdcall - Possible?

Question

I have a program that I need to create a DLL for, hopefully in C#. The program is written in Delphi and I have an interface file to code to. The interface uses the stdcall

Answer 1

This is not possible in pure C#, but this is an article that shows how to add an unmanaged export table to your C# library, which can then be used in any other language. Note that the hordes of references to Blitz should not put you off - they relate to the author's own context and have nothing to do with the basic concept and how it works.

There is also a section in Brian Long's one conference paper. In a twist that you could see as somewhat ironic, Delphi.Net actually supported unmanaged exports directly despite C# not doing so. I have no idea if this is true of Delphi Prism as well.

Answer 2

I found a post from Robert Giesecke on the Delphi Prism newsgroups. In it, he announces a project you can add to a solution that lets you export arbitrary functions from a .Net DLL simply by adding the DllExport attribute to them. It supports marshaling just like DllImport. He demonstrates it with a Prism project, but I imagine it would work on C# classes as well. The post was made in March, so I'm not sure whether the attachment will still be available. The May release of Prism obviates such a tool since it supports unmanaged exports by itself.

Answer 3

You need to make the assembly (=C# DLL) accessible to COM, which is called Interop.

See MSDN articles Assembly to Type Library Conversion and Packaging an Assembly for COM which describe the technical background and the utilities to perform the required operations.

Answer 4

I'm quite sure this can not be done directly. You'll have to either write a layer in C++/CLI or expose the C# code as an ActiveX interface. But that second option may not meet your interface.

Answer 5

I have been down this road before. The solution I picked was to create a NEW C# assembly (I later ported this to Prism) which exposed via com interop the functionality I needed to reach. I was finding by black boxing the API calls into something simpler, I was able to reduce the number of classes I had to deal with across the interop barrier.

I did look at Hydra, but it was overkill for what I was trying to do... which was access a 3rd party SDK which was presented in .net assemblies to process data. If you are looking at embedding the functionality (gui objects, ect) in your application then you should give Hydra some consideration.

I did use Managed.VCL for a very early version of the system, but later abandoned it for the Prism/C# com interop approach which was simpler to deploy, and more stable.

Answer 6

Out of curiosity, why are you hoping to write a .dll that's intended to be used from a native application in C#?

Managed C++, Delphi for .Net and now Delphi Prism all support this out of the box using unmanaged exports. By design, C# and VB.net don't. Not sure why. But as Cobus mentioned, you can kind of hack around this. Do so at your own risk.

In addition to Hydra from RemObjects, AToZed is introducing CrossTalk.