Is the same class used in two separate libraries incompatible?
A curious case came in today and it got me thinking about how the object model really works in delphi.
Happening:
We've imported a SOAP service that exposes several methods, taking objects as parameters. Delphi creates classes / interfaces that we use to communicate with the soap service, and the objects used as parameters all inherit from TRemotable.
For various reasons, we transferred all communication with the soap service to dll.
Then we tried to create the objects that should be sent to the main executable and pass them to the library for serialization and dispatch.
Now it didn't work, but I gave an exception that I was not expecting.
He said that the object where we are trying to send the soap service should inherit from TRemotable, but it does. Inspecting the object, we can see that the class is an imported class from wsdl and that the parent class is indeed TRemotable.
Build with packages solves this problem.
Question:
Is it so that a class defined in a source file shared between two libraries ends up as different classes at runtime? If so, why?
As far as I know, it should be good to transfer objects between libraries. How is reliable typing ensured, and how will the instance instances be compatible with each other?
source to share
Yes, the same class is different in different DLLs. The classes in each DLL will be loaded at runtime and point to a different memory, so A.ClassType = B.ClassType
will fail even for the same source files. You can still pass objects, and they will work correctly, except in cases like this where it uses "is" or "as" to compare the classes themselves. Strong typing is provided only by the fact that the compiler assumes that the classes match when compiling the DLL and the main application. There is no protection against loading a DLL with one version of an object and a newer application trying to use a modified object declaration. If you want you to need to use packages.
source to share
You can try passing the parameter as TObject, and from either end as your TRemotable. I have not tried this specific case, but I know I have passed a TObject into a DLL like this. I also have a similar DLL for SOAP and it won't work in my case as my SOAP DLL is compiled with DAP7 SOAP libraries and for complex / legacy reasons, the rest of the application is D2005.
source to share