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 calling convention.
Is it possible to create a C# DLL that conforms to the interface and can be used in the Delphi application?
Is there some sample code that demonstrates how to code the C# DLL to a stdcall interface method?
This is not directly possible. C# is managed code. This means that it requires a very specific runtime environment in order to function, an environment which Delphi could not directly provide to it. It is not like C where you simply find the address and calling convention of the function and call it.
However, it is possible to host the Common Language Runtime inside of a Delphi application (or any other Windows application). I have no idea how to do this. I just know that it's possible. (It's quite likely that's what this 'Hydra' that Steve mentioned will do.)
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.
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.
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.
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.
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.
I'm assuming here that the Delphi app is not a .NET based app and therefore you need to host the .NET runtime in a Win32 process.
CorBindToRuntimeEx is a function inside MSCorEE.dll, which holds the .NET runtime. With it you can host the runtime and then create objects inside it and interact with them.