Interprocess communication
-
How to make one DLL communicate (tap into data) with another DLL in runtime which will be linked to a different executable. Both DLLs are being written by me. The source DLL (one that obtains data) is 99% completed and it is regular .NET C# class library and it gets used by executable A.EXE. Source DLL reads from Socket so once it reads the data, it is gone from Socket, so entry class is implemented using Singleton pattern (private constructor + reference to self + static public accessor) The new DLL is going to be in C++ (with its public functions all extern "C") and it gets loaded into memory by a legacy application that looks at same data differently. Both DLLs cannot be kept in same folder and Source DLL cannot be loaded multiple times...
---- Did Microsoft finally solve the DLL Hell?
-
How to make one DLL communicate (tap into data) with another DLL in runtime which will be linked to a different executable. Both DLLs are being written by me. The source DLL (one that obtains data) is 99% completed and it is regular .NET C# class library and it gets used by executable A.EXE. Source DLL reads from Socket so once it reads the data, it is gone from Socket, so entry class is implemented using Singleton pattern (private constructor + reference to self + static public accessor) The new DLL is going to be in C++ (with its public functions all extern "C") and it gets loaded into memory by a legacy application that looks at same data differently. Both DLLs cannot be kept in same folder and Source DLL cannot be loaded multiple times...
---- Did Microsoft finally solve the DLL Hell?
You can use File Mapping[^] to share data between processes. If you simply want to send messages from source to sink, you could alternatively use Named Pipes.[^] I believe the .NET Framework contains classes for each of these objects.
The difficult we do right away... ...the impossible takes slightly longer.
-
How to make one DLL communicate (tap into data) with another DLL in runtime which will be linked to a different executable. Both DLLs are being written by me. The source DLL (one that obtains data) is 99% completed and it is regular .NET C# class library and it gets used by executable A.EXE. Source DLL reads from Socket so once it reads the data, it is gone from Socket, so entry class is implemented using Singleton pattern (private constructor + reference to self + static public accessor) The new DLL is going to be in C++ (with its public functions all extern "C") and it gets loaded into memory by a legacy application that looks at same data differently. Both DLLs cannot be kept in same folder and Source DLL cannot be loaded multiple times...
---- Did Microsoft finally solve the DLL Hell?
-
ExcellentOrg wrote:
How to make one DLL communicate...Source DLL reads from Socket
As a wild guess - use a socket.
@ExcellentOrg despite the tone both answers are correct. And you may have long ago solved this problem .... especially since so much time has passed. Me, I would probably go with the TCP/IP solution for no better reason than one is essentially a server the other a client and as long as you which starts when that should be easy. Named pipes seem to be very cool and work really well in a 1:1 application. Doug
I am a Traveler of both Time and Space
