Consume .NET assembly in Delphi XE2

5.6k views Asked by At

I have some of the business logic implemented in .NET and some in Delphi. Now i am planning to upgrade to Delphi XE2.

Do we have any provision to consume .net assembly from Delphi XE2?

Update: I heard about Hydra framework which enable us to integrate managed and unmanaged code. Can anyone explain more about it with a small demo / code snippet?

Update: I have tried few things on Trial version of this Hydra Framework. But it requires to modify your .NET assembly as well to create interface so that we can map this with Delphi code.

Is there any way to consume .NET assembly without modifying it?

4

There are 4 answers

1
Remy Lebeau On

Have a look at AToZed CrossTalk, it can consume .NET assemblies directly without using COM interop.

3
Pete Stensønes On

Nilesh, I can only answer this from the presepctive of Delphi 6, so please bear in mind that Delphi XE2 may have newer .NET interop options.

So to consume (your) .NET assembly functionality from (your) Delphi 6 app the simplest way is the modify the .NET assembly to be COM visible and simply consume said COM interface the normal way in Delphi.

From the .NET project; extract the functionality you need into an interface (or interfaces) apply a GUI attribute to those interfaces. In the project options mark the project as "COM Visible" and rebuild. You'll need to register the assembly with COM (run regsvr from the command line on it if memory serves!)

From Delphi; perform an import of the type library to get the TLB from the assembly DLL, then just CoCreate() with the approriate GUID and consume just like any other COM librabry.

0
Fabricio Araujo On

You can do what is called unmanaged exports.

Delphi Prism supports it in the language, C#/VB.NET doesn't. But there's a project template to use that, see in the author site.

Unmanaged exports is a technique that's allow native code call managed code without COM interop. Mr. Giesecke have an article on the subject.

0
Arnaud Bouchez On

About XE2, the only possibly breaking new feature shall be 64 bit.

But from the COM point of view, it may matter for a COM object to be implemented or called in either a 32 bit or 64 bit code.

COM object types are registered via registry keys. This is what the regasm.exe utility does (writes to the registry). 32-bit bit registry nodes and distinctly different than 64-bit registry nodes.

For instance, if your COM object is compiled as 32 bit, it shall be registered in the 32 bit registry or the 64 bit registry (via reagasm calls)

But if you stick with 32 bit Delphi application, you won't have any additional issue, if you specify the COM wrapper to be exported as 32 bit. In short, XE2 behaves exactly the same as any previous version of Delphi, when creating 32 bit processes.

See http://www.gfi.com/blog/32bit-object-64bit-environment for additional information.

Another solution could be to run the COM object out of the process: in this case, the bit-ness won't matter, and you should not have any issue about 32 or 64 bit.

Be aware that there was a very annoying bug in XE2: in short, COM access was broken in some cases. Sounds like latest "Update pack 2" solved the issue.

Of course, if you use the cross-platform features of Delphi XE2, your COM object won't be available in Mac OS X. ;)