Hydra and static linking

Hydra
1

Hello,

our build servers still compile our applications with runtime packages. But because of the debugger issues with runtime packages and the new dll loading mechanism in Windows 10, we have started to build our application on development machines without runtime packages. This makes a huge difference for debugging purposes.

Today by chance I opened the ‘Hydra Project Package Settings’ and the following line caught my attention:

“Hydra Applications need to be built with Packages”.

What is the reason for this? So far statically compiling Hydra into our app has been working fine for us.

Thank you!

2

Hi,

Hydra should be built with runtime packages only if you pass Delphi objects (i.e. descendants of TObject), etc between host and plugins.

If you don’t need to pass Delphi objects, host and plugins can be built w/o runtime packages.

in this case, VCL plugins should export only HYGetCrossPlatformModule method and not HYGetModuleController name name_HYGetModuleController method.

FMX plugins should export both functions in any way

exports
  HYGetCrossPlatformModule,
  HYGetCrossPlatformModule name name_HYFMGetModuleController;
3

Thanks for the info!

We actually use plenty of Delphi Objects that inherit from THYFakeIDispatch and implement IHYCrossPlatformInterface.

So far we have not noticed any problems. What type of problems should we then expect when statically linking Hydra and passing Delphi objects between C# and Delphi?

Thanks!

4

you will catch problems only if delphi objects are passed as is in interfaces like

IMyInterface = interface(...)
..
   procedure test(param1: TStringList);  // << delphi object is used here
end;

if objects are passed as interfaces, like

IMyInterface = interface(...)
..
   procedure test(param1: ISecondInterface);
end;

it will work w/o any issues.
ofc, ISecondInterface also shouldn’t use delphi objects as parameters.

5

That is something we do not do.
So we are safe with static linking. :slight_smile:

Just for curiosity what type of problem would you encounter in such a case, would it be a compile time or runtime error?

Thanks!

6

this is runtime error.

//SAssignError = 'Cannot assign a %s to a %s';

procedure TPersistent.AssignError(Source: TPersistent);
..
  raise EConvertError.CreateResFmt(@SAssignError, [SourceName, ClassName]);
end;

for IMyInterface interface, it will be Cannot assign a TStringList to a TStringList

7

Hi, I’m trying to develop an RO Server that supports Hydra RO Service plugins, and I don’t want to build with runtime packages. I tried what you suggested and changed the exports section as per your suggestion, only export HYGetCrossPlatformModule. But when loading the dll plugin I get a hydra error that my dll is not a valid hydra module.
What am I doing wrong here?
I’m using Hydra 4

8

Hi

just a question only for understand. Why don’t you want to use runtime packages? I use it’s in server and client side without problems from many years. Debug is not a problem. The dll’s and executable are very small and in client side I use all devepress suite in all plugin modules and work very fine. I created my custom runtime package for every macro area: RTL and VCL are one package, RO/DA/HY are one package ecc ecc so I always have control over the package that I distribute

9

Hi,

I have also created my own runtime packages, for both server and client. But sometimes maintenance becomes a nightmare. What my plan is to keep client as is with runtime packages, but for server I wish for it to be more lightweight without having to maintain these packages too. And to be honest, at some point I will convert it to console or service so it will have none dependencies on VCL but still being able to use plugins to extend functionality or deploy for a completely different project.

10

Hi,

THYModuleManager should have LoadUnmanagedCrossPlatformModule method.

if your version of Hydra hasn’t this method then this possibility were added after your version of Hydra and you should update Hydra.

11

Hi,
I decided to give this approach another try, but before I proceed with upgrading to the latest Hydra version I want to be clear that it will be able to do what I’m trying to achieve.
So you mentioned that with LoadUnmanagedCrossPlatformModule method, .dll plugins can be loaded without the need for runtime packages for both host and plugins. Having this in mind, can I put in my host application the ROServer and HYModuleManager components and load plugin modules with RO and DA services? Will this work? Will both host and plugins share the same classes?

12

Hi,

in case of RO/DA services, your host and plugin should be built with DA_Server run-time package (of course, RO_Core, RO_Server, DA_Core packages are also required)

I can recommend to install .1267 build.
it allows to create RO/DA service plugins w/o Hydra_VCL run-time package.

also it contains the Remoting SDK Modular Server sample. it’s almost the same as you want.