The plan I’m trying to follow is to create a new development VM (based on Win 10 and VS 2017), purely for .NET DA and / Hydra visual plugin work. An existing VM is based around Win 7, VS2012, Delphi XE2, Hydra 4, DA 8.
A couple of related questions :-
1). Should plugins created in VS2017, using the latest Hydra 6 be compatible with a Delphi XE2 host built using Hydra 4 ? Having tried this, I get the plugins loaded, but when the plugin form is in the process of being displayed, it totally closes down the host application after a pause of 20 seconds or so. Given I’m using two development machines, I’ve not had chance to dig into this to see if I can pin down where the failure is occurring. Given I’m using Hydra 4 on the Delphi host and 6 in the .NET plugin, I’m not surprised. Should I pursue this and expect it to work though ? Ideally I’d like to not touch the Delphi environment for now, but making use of Hydra 6 on the Delphi XE2 side seems like it would be necessary ?
2). Assuming I need to use Hydra 6 on the Delphi XE2 side, I’ve started exploring that route. After a successful installation of Hydra 6 (XML log below), I get the following package errors when loading XE2.
1). I’ll pursue the Hydra 4 route and look to investigate further why the host application crashes out when opening the .NET Hydra 6 plugin.
2). I should have no other Delphi installed packages that use Hydra. I do have the full RemObjects VCL suite in XE2, but are there dependencies in there on Hydra ? At this point given I’m looking to go down option 1, this is not important though.
Pursuing the Hydra 4 route, I’m doing a remote debug from the XE2 environment onto the new environment, running a little test host application. As per my main application, it will load a plugin created in the new environment (hydra 6), but fails when trying to display it. Here’s the error point :
I should also add, that when running the same executable on the original development VM, it will successfully load and display the plugin that was created on the new VM using VS2017, and Hydra 6. As per your first reply, that does suggest that presenting Hydra 6 plugins to a Hyrda Delphi XE2 host should work.
The easiest approach would be to send us to support@ the built project. I’ll run it on a clean environment and will try to intercept the error that happens in the .NET domain.
Or you can try to debug it by yourself:
Start a new Visual Studio 2017 instance
Start the host application
In VS issue Debug → Attach to Process
Attach to the running host app
Go to Debug → Options and make sure that the option ‘Enable Just My Code’ is NOT selected
Press Ctrl + Alt + E
‘Exception Settings’ pane will appear
Expand the Common Language Runtime Exceptions node and check the System.Reflection.TargetInvocationException exception
In the host app try to load the plugin
VS should pause execution and display the exception info. There should be a property InnerException. It will contain the information about the underlying exception and what caused it
Thanks Anton. I’m trying to dig into this myself (but hitting some barriers) .
My issues here may be one root cause, but I have two things to pursue at the moment, so I’d like to clarify them in my own head before presenting them to you. One consistent failure I’m seeing is this.
No error is thrown whilst stepping through the THYModuleManager.ReleaseInstance, but is immediately upon returning. This does NOT happen when using the plugin compiled under Hydra 4 in VS2012, but does using the VS2017, Hydra 6 compiled one.
Generally, the Hydra 6 plugin is loading, and interfaces are able to be called. Releasing the plugin (as above) seems to be one issue). The other issue I can’t describe clearly at the moment, but it could be along the lines of interfaces back into the host are causing problems.
As I said, I’m trying to simplify the test case(s), but I’m currently blocked by the other issue I linked to above.
The production plugin I’m working with here is a visual one. I do have a non visual one in the same module that I can try and see if that fails at the same release point.
In the module I’m working on, I have 5 visual plugins and 1 non visual. I’m only creating an instance of one of the visual plugins i.e. not creating the non visual one.
Would removing the non visual plugin from the module make a difference ?
Is there a difference between removing and “disabling” the non visual plugin ?
I’m aiming to produce a simple test case for this, not involving production code which has database links and other dependencies. I’m currently reinstalling VS 2017 on another snapshot of my new VM to try and see if that helps with the issue that is blocking me progressing this i.e. the one I linked to at the top of this thread. Maybe not you’re area, but if you have a view on that, it might help with this issue or at least let me progress in making a simplified test case.
Just to bring the thread to a slightly inconclusive end…
In one of my earlier screenshots there is a call from the host into the plugin
I found that without that call, the module instance would release without problem. I modified the “NotifyFormClose” call to return a boolean, re-imported the interface to the host and it worked. I further modified the interface back to how it was i.e. to not return anything and it still worked.
I’m fairly confident that I imported the interface to the host when I started working on the plugin conversion initially i.e. the host and plugin should have been in line. If that is the case, then all that has effectively changed is that the source file containing the interface definition has been saved ( return value added and then removed) and reimported to the host when the DLL is built.
From my side, the release of the plugin is working without issue. I have numerous other plugins to convert to Hydra 6 and the latest elements, so maybe they will throw up similar issues. If not, I’m happy to put it down to me possibly not having imported as fresh version of the the interface when the plugin was converted to Hydra 6 / latest VS2017 / Elements. That said, nothing having changed on the interface, I don’t think I should have needed to anyway.
Thanks for replying, but I don’t think this is worth your time.
I’ve just been through it again, using a clean copy of the interface file i.e. the same as I would have had originally.
I built the plugin DLL, then re-imported the interfaces to the Delphi host, recompiled and tested it out. It worked without issue. So I can only assume it was something on my side, not a problem for you as far as I can tell.
I still have numerous plugins to carry over from my old VS 2012 Hydra 4 environment, but they all use the same interfaces, so I’m hopeful I’ve seen most of the issues already.
