Consume .NET assembly in Delphi XE2

I have part of the business logic implemented in .NET, and some in Delphi. Now I plan to upgrade to Delphi XE2.

Do we have any condition for using .net assembly from Delphi XE2?

Update: I heard about the Hydra framework , which allows us to integrate managed and unmanaged code. Can someone explain this with a small piece of demo / code?

Update: I tried several things in the trial version of this Hydra Framework . But it also requires changing your .NET assembly to create an interface so that we can map this to Delphi code.

Is it possible to use a .NET assembly without modifying it?

+4
source share
4 answers

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

+3
source

Nilesh, I can only answer this from the pre-sale Delphi 6 , so please keep in mind that Delphi XE2 may have newer .NET interaction options.

So, in order to consume the (your) .NET assembly functionality from (your) Delphi 6 application, the easiest way is to modify the .NET assembly to be visible to COM, and just consume the mentioned COM interface in the usual way in Delphi.

From the .NET project ; extract the necessary functions into the interface (or interfaces), apply the GUI attribute to these interfaces. In the project options, mark the project as "COM Visible" and rebuild. You will need to register the assembly with COM (run regsvr from the command line if there is memory!)

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

+1
source

About XE2, the only possible new feature is 64 bit.

But from the point of view of COM, this can be important for the COM object to be implemented or called in either 32-bit or 64-bit code.

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

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

But if you stick with the 32-bit Delphi application, you will not have any additional problem if you specify COM packaging for export to 32 bits. In short, XE2 behaves exactly like any previous version of Delphi when creating 32-bit processes.

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

Another solution could be to start a COM object from the process: in this case, the bit version does not matter, and you should not have problems with 32 or 64 bits.

Remember that there was a very unpleasant mistake in XE2 : in a word, in some cases access to COM access was violated. Looks like the latest “Pack 2 Update” resolved the issue.

Of course, if you use the cross-platform features of Delphi XE2, your COM object will not be available on Mac OS X .;)

+1
source

You can do so-called unmanaged exports .

Delphi Prism supports it in the language, C # / VB.NET does not. But there is a project template that can be found on the website.

Uncontrolled export is a method that allows you to manage managed code without COM interaction. Mr. Giesecke has an article on this subject .

0
source

Source: https://habr.com/ru/post/1344498/


All Articles