I have an application made up by a service and some DLLs loaded dinamically. Both the application and the DLLs are compiled with run-time packages - it looks that using both run-time packages and sharemem could bring to some issues (see quality central) - building with run time packages should make the application and DLLs to use the same memory manager.
I run into a serious issue while trying to share a session between the application and a DLL. I am passing the session as a generic TObject to avoid a tight coupling, and when I tried to cast it to a TOracleSession I get an "invalid cast" error.
Inspecting it, I found that the ClassType of the passed session and the local one were different. I guess that because DOA have no run-time packages, DOA gets initialized both in the DLL and the main application, and I end up with the same class in two different VMTs, or something alike.
I did not test it with sharemem yet, but that's a solution I wish I could avoid for several reasons.
Moreover, I thought that without a run-time package other issues could arise, for example DOA units will be implicitly imported in any package using them.
It's difficult to understand why DOA was never split in a desing/runtime coupe as almost any other good library does - I see it was requested years ago, and should not be very difficult to do.
As said in my previous post, DOA would deserve a version 5 soon, with many improvements in many areas. DOA is becoming a bottleneck - and we will be forced to remove it if nothing new happens.
I run into a serious issue while trying to share a session between the application and a DLL. I am passing the session as a generic TObject to avoid a tight coupling, and when I tried to cast it to a TOracleSession I get an "invalid cast" error.
Inspecting it, I found that the ClassType of the passed session and the local one were different. I guess that because DOA have no run-time packages, DOA gets initialized both in the DLL and the main application, and I end up with the same class in two different VMTs, or something alike.
I did not test it with sharemem yet, but that's a solution I wish I could avoid for several reasons.
Moreover, I thought that without a run-time package other issues could arise, for example DOA units will be implicitly imported in any package using them.
It's difficult to understand why DOA was never split in a desing/runtime coupe as almost any other good library does - I see it was requested years ago, and should not be very difficult to do.
As said in my previous post, DOA would deserve a version 5 soon, with many improvements in many areas. DOA is becoming a bottleneck - and we will be forced to remove it if nothing new happens.
