InstanceID deprecated - is there an alternative?

I have an application written in Delphi7 (both the Host and visual plugins).
I have recently upgraded to latest Hydra in an attempt to migrate plugins then finally the host into c# .net

The D7 host/plugin framework uses InstanceID in order to locate plugin instances in an ObjectList. A plugin makes a call to back to the host interface using GetInstanceID to identify a plugin instance. The host locates the plugin in an objectList using the instance Id provided.

// Locate the plugin in the manager using it's unique plugin ID.
function TDockedFormManager.FindItemIndexByInstanceID(i_InstanceID: integer): integer;
  i: integer;
  Result := -1;
  for i := 0 to count-1 do begin
    if (assigned(items[i].IntfPointer)) then begin
      if (items[i].IntfPointer.InstanceID = i_InstanceID) then begin
        Result := i;

I’m now attempting to dock the .net plugins into the same D7 host. I make the same call back to the host from the .net plugin using “this.InstanceID” in the plugin in to identify it.

This call does return an integer value (1 for first plugin instance, 2 for second plugin instance etc), but the InstanceID value returned in .net does not match the InstanceId in Delphi returned by the call to items[i].IntfPointer.InstanceID.

Looking through your docs I see the following

InstanceID protected
Gets the InstanceID to determine the run-time identifier of the plugin instance. Deprecated .

I assume I can no longer user InstanceID? What are the alternatives, I’m trying to avoid recoding the D7 as much as possible, and apart from this issue (and a couple of other minor ones) its seems to be working ok.



InstanceID is an internal host-specific plugin identificator.
For Delphi hosts address of plugin wrapper is used.
.NET plugins auto-generate a stub integer value, however it is not used on the host side. Actually this confusing behavior was one of the reasons to deprecate this property.

You can continue to use the InstanceID property for now. I will log an issue to revisit this property and make its behavior less confusing (no ETA on this).


Thanks, logged as bugs://83751