Jump to content
BastiFantasti

Build managed dll in Delphi

Recommended Posts

HI @all

 

is there a way to create a managed code dll suitable for integration in .net applications?

 

There is a separate commercially available Delphi / Objective Pascal for .net from RemObjects (Oxygene),

but I wanted to know if there's a way to do it with e.g. Delphi 10.4 directly.

 

Thanks in advance

 

Best regards

Bastian

 

 

Share this post


Link to post

You can't make managed code with Delphi. What you can make is an unmanaged DLL that can be wrapped from managed code in .NET.

Oxygene is native .NET.

Share this post


Link to post

Hi Lars,

 

thanks for your quick reply. I was afraid of something like this.

 

Ok so we have to go with with Oxygene or provide a wrapper  which does the marshalling

 

Best regards

Bastian

 

Share this post


Link to post

Just write your DLL as an in-process COM server (or out-of-process if that suits your need better). .NET can use that directly.

  • Like 1

Share this post


Link to post
10 hours ago, Der schöne Günther said:

Why not stick with a native dll and use that from .net?

That is what I would suggest, too.  Granted, writing PInvoke wrappers is not always the easiest task, but it does work well if you get it right.  I've written several DLLs (in C++) that are used in C# via PInvoke.

Share this post


Link to post

Thanks @all for your replies and tipps. 👍

 

I will check out the mentioned possibilites and see what fits our needs best.

 

Best regards

Bastian

 

Share this post


Link to post

Whether you opt for pinvoke or a COM server depends very much on what the interface surface area looks like. I don't think anybody can give you a valid recommendation without knowledge of that.

 

Broadly speaking, for more larger and more complex interfaces, then a COM server may be preferable. For simpler interfaces, then p/invoke may be preferable. It is more effort to setup a COM server (especially if you have to learn COM), but having done so the coding on both sides will likely be simpler. For larger and more complex interfaces the startup cost of a COM server will yield time savings to offset that. For an interface that can be represented by a small number of functions, then you will never recover that startup cost, hence why p/invoke would win.

 

To my mind at least those are the main factors to consider in your decision.

  • Like 1

Share this post


Link to post

While I completely agree with David's considerations it should be noted that the startup cost of an in-process COM server is considerably smaller than that of of an out-of-process COM server. For an in-process server it's basically just the cost of setting up the COM apartment. For an out-of-process server there's also the cost of launching the process.

 

In the cases where I have chosen to use COM for interop with .NET it has mostly been because of the convenience of not having to worry about marshalling and because it's so easy to just wrap a Delphi object in an interface/TAutoIntfObject and pass that on to .NET

Share this post


Link to post
8 minutes ago, Anders Melander said:

While I completely agree with David's considerations it should be noted that the startup cost of an in-process COM server is considerably smaller than that of of an out-of-process COM server. For an in-process server it's basically just the cost of setting up the COM apartment. For an out-of-process server there's also the cost of launching the process.

I meant the startup cost for the developer to learn how to create and maintain and deploy com servers. 

Share this post


Link to post
1 hour ago, David Heffernan said:

I meant the startup cost for the developer to learn how to create and maintain and deploy com servers. 

Ah :classic_smile: Yes, that too. Not insignificant but once you know, you know.

Share this post


Link to post
26 minutes ago, HalfBlindCoder said:

Though I am very much new in Delphi development but somehow i managed to use Delphi dll inside .net win forms application using this library. https://github.com/3F/DllExport

No. That's a library for creating unmanaged exports from a managed library. So you take a C# library and use DllExport attributes to allow unmanaged code, like Delphi, to consume that C# library with LoadLibrary, GetProcAddress, etc. 

 

The question being asked here is very different. It asks if it is possible to make a managed library with Delphi. And that isn't possible. 

Share this post


Link to post
5 minutes ago, David Heffernan said:

No. That's a library for creating unmanaged exports from a managed library. So you take a C# library and use DllExport attributes to allow unmanaged code, like Delphi, to consume that C# library with LoadLibrary, GetProcAddress, etc. 

 

The question being asked here is very different. It asks if it is possible to make a managed library with Delphi. And that isn't possible. 

Thank you sir, I misunderstand the topic. Thank you for correcting me.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×