BastiFantasti 0 Posted April 8 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
Lars Fosdal 876 Posted April 8 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
BastiFantasti 0 Posted April 8 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
Anders Melander 766 Posted April 8 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. 1 Share this post Link to post
BastiFantasti 0 Posted April 8 Thanks for that hint. I'll look into that option! Share this post Link to post
BastiFantasti 0 Posted April 8 Would this be an "ActiveX Library"? In the Delphi Project Templates? Share this post Link to post
Anders Melander 766 Posted April 8 45 minutes ago, BastiFantasti said: Would this be an "ActiveX Library"? In the Delphi Project Templates? Yes, I think it is. It's been a while since I did it though so I could be wrong. Maybe start by reading the help http://docwiki.embarcadero.com/RADStudio/Sydney/en/Developing_Interoperable_Applications_Using_COM Share this post Link to post
Der schöne Günther 132 Posted April 8 Why not stick with a native dll and use that from .net? Platform Invoke (P/Invoke) | Microsoft Docs 1 Share this post Link to post
Remy Lebeau 566 Posted April 9 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
BastiFantasti 0 Posted April 9 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
David Heffernan 1288 Posted April 9 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. 1 Share this post Link to post
Anders Melander 766 Posted April 9 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
David Heffernan 1288 Posted April 9 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
Anders Melander 766 Posted April 9 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 Yes, that too. Not insignificant but once you know, you know. Share this post Link to post