Upgraded to H5, .NET plugins no longer load

I am maintaining an application in Delphi XE that has used a small, non-visual plugin I wrote in Visual Studio 2015 with Oxygene. It’s been working with Hydra 4 quite well.

I recently upgraded to Hydra 5 (5.0.85.1141), recompiled both the Delphi app and the .NET plugin and now I get an error when it tries to load the plugin.

When I originally wrote the .NET plugin, I also wrote two other plugins, one in Delphi, and another one in .NET that were very simple, just test plugins to show a message. I used these to learn how to use Hydra and prove that the plugin system was working as I tested in various environments.

Testing with these two very simple plugins, I found the Delphi plugin works fine, but the .NET one does not. Once again, these are the simplest, non-visual plugins that could be written.

The error I get when I call HYModuleManager.CreateNonVisualPlugin breaks in THYManagedPluginFactory.CreateInstance with the error “Interface not supported” quickly followed by “Unknown update list {…GUID…}.”

I did not see an “update notes” document. Is there something I’m supposed to do different when using Hydra 5? An interface change or class attribute I missed?

Can you reproduce this issue with the latest RTM (5.0.87.1149) ?

Hmm… I had run the “Check for new versions” from the Everwood Welcome screen and it didn’t show a new version of Hydra–I had only downloaded it a few weeks ago, so didn’t think to check myself. But yes, there is a newer build.

Alas, after installing the latest build and recompiling all the libraries and double-checking all files are up to date, and rebuilding both the Delphi app, plugin, and VS plugins, I’m getting the same problem. :disappointed:

There is one slight difference: it breaks just a few lines earlier in THYManagedPluginFactory.CreateInstance when it’s calling CreateManagedPluginInstance with the error message: “Exception has been thrown by the target of an invocation.” (Previously, it was breaking on the last line of the CreateInstance method.)

Not sure if that means anything.

can you create a simple testcase, that reproduces this problem, pls?
you can send it directly to support@ or attach it here.

Here are three ZIPs of source code: a test Delphi XE Hydra app, a test Delphi XE plugin, and a test .NET plugin written with Oxygene 8.3 in VS 2015.

LoadNonVisHydraTest.zip (7.3 KB)
TestDelphiPlugin.zip (7.4 KB)
TestDotNetPlugin.zip (11.7 KB)

Here are relevant portions of the information returned in Visual Studio’s About box…

Microsoft Visual Studio Community 2015
Version 14.0.23107.0 D14REL
Microsoft .NET Framework
Version 4.7.02053

RemObjects Elements 8.3.91.1965

RemObjects Hydra for .NET 5.0.87.1149

Hello

The issue you have if caused by the missing licenses.licx file.
Despite it is mentioned in the .oxygene project file, the licenses.licx file itself is missing from the Properties folder. This makes it not possible to instantiate the plugin while loading.

You need to manually delete the line

<EmbeddedResource Include="Properties\licenses.licx" />

from the .oxygene file and then readd the licenses.licx file (f.e. you can take one from the Mixed Mode sample.

Regards

I have the licenses.licx file in my system, but left it out of the bundle I posted thinking it might contain private information.

There’s no private information in it. It is just a plain text file. Could you drop it to support@ as well or post it here?

Here’s the file. Strange that it refers to the .85 build instead of the .87 which is installed.

licenses.zip (258 Bytes)

Well, this explains why it worked earlier and started to fail now.

licenses.licx has version # explicitly specified. When the plugin is being build, .NET licensing system checks your license and complies .licx file into a resource. Issue is that this compiled resource contains licenses for Hydra assemblies others that are used by the plugin. So it fails with licensing error as expected.

You neeed to change the licensing.licx file to this single line:

RemObjects.Hydra.NonVisualPlugin, RemObjects.Hydra

Then delete the obj folder in your project’s folder (VS doesn’t always do this even on build cleanup) and rebuild the plugin. Everything will work as it should after that.

Regards

Thanks! That worked.

But it leaves a couple of questions… Why was the version information in there in the first place? I never manually edited the license file before. Do I have to check the license file for other .NET projects?

Hello

Visual Studio does that for you (it is not our code, it is just how VS works). When it detects that one just have added a component that requres .NET licensing stuff (either dragged some component from the Toolbox or added something via the ‘Add New Item’ menu, like Non-Visual Hydra plugin) VS does the folllowing:

  • It scans the current project for licenses.licx file
  • If there is no such file it is added
  • Contents of the file is scanned for a line that satisfies the license definition of the entity just added (* see below)
  • If such line is not found then the license definition is added to the .licx file containing full assembly information including version #

Note: By ‘satisfies’ here I mean that f.e. if you just have added a Non-Visual Plugin and referenced Hydra build 5.0.87.1149 then VS will check for lines

RemObjects.Hydra.NonVisualPlugin, RemObjects.Hydra, Version=5.0.87.1149, Culture=neutral, PublicKeyToken=3df3cad1b7aa5098

and

RemObjects.Hydra.NonVisualPlugin, RemObjects.Hydra

(ie license definitions with ful correct version info or w/o any version info at all).


It is better to. Actually you can just run a search on all licenses.licx files containing word “PublicKeyToken”. This search will show all license files with excessive version information.

Regards

Thank you for this explanation. I appreciate the help in getting to the bottom of this. :sunglasses:

Anton,

can we improve on the error handling to make it more clear that the licensing is what causes the problem, rather than the obscure error message?

—marc

Thanks, logged as bugs://78184

Depends on how much exception info does care COM to send out, I’ve logged an issue to investigate this issue.

bugs://78184 got closed with status fixed.