Mixed-Mode Applications: Combining Delphi, .NET, Silverlight and Island

Hydra 3 introduced a new direction of our well-received plugin framework. While previous versions of Hydra were targeted solely at Win32 Delphi developers and enabled them to build plugin-based systems for that platform, Hydra 3 widens the scope of the product by providing support for a new goal and target audience: Delphi developers that seek to leverage the .NET framework in their application development.

Hydra 4 expanded on this to also add support for Silverlight plugins, as well as FireMonkey and 64-bit Delphi hosts and plugins.

Hydra 5 added support for creating CPU native plugins in Oxygene, C#, Swift and Java via our Island platform in Elements 9.1 and later, and mixing those into your Delphi or .NET host applications, as well.

And with Hydra 6, Java plugins are supported as well!

A Brief History of .NET in the World of Delphi

Ever since it was originally announced, the Delphi community has had a love/hate relationship with .NET. Being spoiled by the richness in RAD development they had been enjoying for years, the community was quick to dismiss .NET as something that might bring benefits to MFC or Visual Basic developers, but would bring little benefit over Delphi and its powerful VCL class library and RAD form designers. Many also saw .NET as the latest development fad that would excite people for a while but quickly die out for lack of serious adoption.

Three significant releases later, it has now become obvious that these assumptions were wrong. The .NET 2.0 core framework has introduced significant development advances in the .NET languages, such as Generics that make .NET development attractive and, with the new services branded under 3.0, Microsoft has introduced a significant new paradigm for user interface design that is likely to revolutionize how tomorrow's Windows desktop applications will look and feel. The third party market for .NET has developed strongly, with a vast range of professional components being available in all imaginable areas – while at the same time the Delphi component market seems to be winding down, as many third party vendors scale down their support in favor of .NET or are leaving the market altogether.

Switching from Delphi to .NET?

As developers eye the new features and technologies becoming available on the .NET side, it becomes an attractive option to leave Delphi behind and fully leverage the new platform for future development.

Unfortunately, this is not an easy decision for many developers, for a multitude of reasons. To start with, most developers are not in a vacuum and able to start fresh on a new project, but have existing code bases written in Delphi, either in the form of existing projects that need to be extended and maintained, or at least have large class or function libraries or base frameworks that are time-proven and well-tested. These days, while customers expect ever more features and better quality in less and less time, it is usually not economically feasible to just abandon the entire investment in existing Delphi code (often many thousands or even millions of lines of code) just to get the product to a new platform.

Just like Microsoft is not dropping everything and rewriting Office in .NET (as many .NET-skeptics often demand as a sign of Microsoft's trust in their own technology), most commercial Delphi developers cannot afford to throw away their investment just to start clean.

Embracing .NET with Delphi

This is the situation that triggered the initial idea for Hydra cross-platform plugins: what if there was a way for Delphi developers to preserve their existing investment in solid, working Win32/Win64 code written in Delphi, but at the same time enable them to extend that codebase, using new .NET-based technologies? What if developers could use .NET, Generics, Windows Presentation Foundation, LINQ and all the other benefits of the .NET framework when writing new code for their applications, while keeping the existing parts of their application code basically untouched without porting and retesting?

This is the vision that we had with Hydra, and that we're delivering with its first release. After a few relatively simple (depending, of course, on project size and complexity) steps for adjusting an application's architecture to be open to extensibility, your Delphi project can be seamlessly extended with new code written in either Delphi or .NET.

Among others, the following scenarios are imaginable:

• Keep your existing application base around indefinitely, but start writing some, most or even all new modules in .NET to leverage new technologies.
• Migrate your application to .NET step by step, eventually resulting in a fully managed application (but at your own pace, while maintaining full functionality throughout the porting process).
• Keep using Delphi to write your application, but allow others (end users, out-sourced developers, etc.) to write plugins using .NET.
• Try out .NET by adding minor new functionality to your application, allowing you to evaluate the platform without big risk or investment.

Because Hydra allows seamless mixing and matching of managed and unmanaged code in any imaginable combination of the above, this gives you the flexibility to plan the move to .NET according to your own needs.

Hydra supports versions Delphi 7 (yes) and later, .NET 2.0 through 4.x in Microsoft Visual Studio 2015 and later (including Visual C#, Visual Basic and all Elements languages, including Oxygene, Java 8 and later, as well as of course active Island plugins.

But let us get a little more technical and see how this works in practice.

Plugins

The foundation of Hydra's extensibility is based on the concept of plugins. Most basically put, a plugin is simply an object that provides a certain functionality that your main application (the host) needs.

Plugins can be written using any of the supported development tools (Delphi, .NET language, Island or Java), and one or more plugin is usually compiled into a .dll, a so-called plugin module. A host application can load any plugin module, regardless of what platform it was developed with, allowing you to mix Delphi and .NET functionality in the same application.

In theory this can be any kind of functionality, but the most commonly used types are either visual plugins or non-visual plugins, for both of which project templates are provided in the supported IDEs:

A visual plugin is a plugin that provides a user interface to be shown within the host application. When developing a visual plugin, a standard design surface (the VCL form designer for Delphi or the WinForms and WPF/XAML designers for .NET) can be used to design the GUI in the familiar way.

The host can then embed the plugin into its own UI in any arbitrary way. How this will look will largely depend on the application. Plugins can be shown on tab-sheets or in separate windows, or they can integrate seamlessly anywhere within a larger form. For example, the Delphi WPF sample we ship with Hydra presents a standard VCL form, but a portion at the bottom of the form is used to show a .NET Windows Presentation Framework based plugin that displays a graph leveraging the next generation display and animation technologies provided by WPF.

Note: As the plugin can be embedded seamlessly into the UI, it is up to your host's decision whether the end user will be able to tell where the host ends and the plugin begins.

Non-visual plugins, as the name suggests, do not normally provide a user interface of their own (although it is entirely possible for a non-visual plugin to open dialog boxes or windows of its own), but instead will be used to perform other tasks or services needed by the host application (such as performing certain calculations).

Talking to Your Plugins via Interfaces

While Hydra's base library provides implementations for the most general tasks involved with working with plugins (for example embedding a visual plugin into your form), most non-trivial applications will need some application-specific communication between hosts and plugins. Going back to the Delphi WPF sample illustrated above, the host needs to inform the plugin of changes to its controls, so the graph can adjust accordingly. Plugins might also need to communicate back to the host, for example in response to user actions within the plugins UI.

This communication is handled with the use of custom interfaces that can be implemented on the plugin, the host or both, allowing the two to call each other. Plugins can implement interfaces to expose the functionality they are providing, just as the host can implement interfaces to make itself accessible to any plugin that is active.

To enable this communication across the boundaries of Delphi and .NET, the Hydra IDE integration provides sophisticated support for converting interface declarations between the two development platforms. You can write your custom interface(s) using .NET code and then import the DLL into Delphi to generate a Delphi unit with the appropriate interface declarations or you can write your interface in Delphi and then import the unit to generate code that compiles under .NET for any of the supported .NET languages.

With some restrictions as to the types that can safely be passed between platforms, you are free to define any and all interfaces you need.

You also have full flexibility as to which of your plugins implement what interfaces. For example, you might define a range of interfaces and have every plugin implement a selective subset. Your host can then use the availability of certain interfaces to determine what functionality is or is not provided by a given plugin, or to decide which plugin to use in which context.

Actions

Another powerful feature that has been part of Hydra since version 2, and that is seamlessly supported for .NET plugins in Hydra 3 and beyond, are actions and menu merging.

Hydra allows plugins (both visual and non-visual) to define a list of actions (comparable to Delphi's Action Lists), as well as a partial menu and toolbar structure that places these actions. Host applications can choose to provide menu merging, allowing the actions defined in the plugins to automatically show up in the host's menu and toolbar system as the plugin is loaded.

Support is provided for the three most popular menu and toolbar systems in use for Delphi: the standard VCL menus, Toolbar 2000 and the Developer Express ExpressBars component suite. Support for custom or other toolbar systems can be easily added, if necessary.

As mentioned above, Hydra supports seamlessly merging actions in menus and toolbars defined in both managed (.NET) an unmanaged (Delphi) plugins into the Delphi host.

Menu and toolbar merging is illustrated by the Actions sample that ships with Hydra, which has been expanded to include a new C# based plugin module to illustrate the concept.

Managing your Modules

For host applications, the Module Manager component is provided to perform the task of managing plugin modules. Available on both the Delphi and the .NET side, you can use the module manager component to load the plugin modules you need. This is based on application-specific logic, which can be as simple or as complex as you wish, for example:

• simply loading a module with a specific name<
• loading all modules from a specific folder<
• using a configuration system to determine which modules to load<

Once modules are loaded, you can use the Module Manager to query for available plugins, check what interfaces are implemented or which .NET attributes were attached to a given plugin, as well as create instances of the plugins you need.

Once again, differences between managed and unmanaged plugins are completely abstracted away and taken care of by the underlying library; your host can simply work with all plugins without ever knowing whether the plugin is implemented in Delphi or .NET (although it can of course find that out, if it needs to).

The mixed mode sample that is shipping with Hydra illustrates the current capabilities of mixing hosts and plugins at will; the sample provides host and plugin implementations for just about all supported languages (Delphi, C#, Oxygene) and platforms (VCL, FireMonkey, WinForms, WPF and Silverlight), and any combination of hosts and plugins can be loaded.

Summary

We hope this page has given you a good summary of mixed-mode applications with Hydra, what goals we are trying to achieve with the product and how the various technical aspects come together to form a full Hydra application.

You can find more in-depth coverage of Hydra on our product wiki and on Channel Hydra on RemObjects TV.