I have coded an application which is meant to be an extension to an already existing program. However, said program doesn’t allow any methods for loading extensions/plugins, or whatever you would call them. For this reason I’ve been thinking over a couple of possibilities, among which are injecting a C++ DLL and going crazy with it, but I’m more interested in doing the entire thing in managed C#.
Both the target program and my own program are written in C#, and therefore managed. Now, I know for a fact that if I set up a reference to the target program in my own project, I can “access” its properties, fields, etc in the Visual Studio editor, but there’s no way I can ever get “real” values from those, since I can’t have the target program run at the time of reading its members, which means I can’t get any “real-world” data from it.
My idea is this: if I were to create a launcher, which injects a DLL (C++, but that’d be the only C++ part) into the target process which sets up an AppDomain, places the host process in that AppDomain, and then proceeds to load my program into the same process and AppDomain, would I be able to access the “real-time” values of the target program?
I know this is a long shot, and actually testing this would take days if not weeks of coding. That’s why I ask here; and perhaps it is a bit too unorthodox and far-fetched, but I think there’s actually a chance this might work. In theory.
So, simplified a bit: Inject DLL into target process -> Create AppDomain -> Place host process in AppDomain -> Load MyProgram.exe into Process and AppDomain -> Access target process’ methods and properties
I’m not sure I understood what you really want to do, but if what you’re going after is to exchange data between an application and another that will be running on the same machine, then why not use WCF communication using the IPC binding (offered by the
NetNamedPipeBindingclass). I believe this is a much more reasonable and easier to maintain and test than your suggested solution.