Marshalling data out of process...

[Sillyboy72]

Getting a DLL loaded in process is clearly the hotness. Thus, we are talking inject a c++ DLL into wow.exe and partying like rock stars.

However, in general, I would still prefer to write my actual bot codez in c#. It's just easier to write, has a better library of collection classes, and it would be nice to tweak the bot w/o worry about unloading/reloading the c++ dll.

Wondering if others have done similar... and how they handled it?

Seems it might make sense to use managed c++ instead of straight c++... to allow some fancy .net way of marshalling the data between the wow process and a c# process. If nothing else, I would get built in serialization/deserialization.

Feels a little wacky to pull the whole clr into wow's process though. and I am still not sure how to actually do the communication. named pipe? something fancy .net way (.net remote? wcf?)

Thx for any good theories

[Xarg0]

Well, WoWSharp used a sharedmemory DLL to implement the IPC between the .NET application and the dll, the down side is you can only run one wow with the dll injected at a time.
You should use a method of IPC that you're familar with and that works good for C# and C++, so you don't need to rewrite an IPC system from scratch, namedpipes are supported in both c++ and c# it's probably the easiest IPC system to implement.

[Cypher]

Shared memory is a terrible way to implement IPC. Just use a pipe.

[argh44z]

When I did (something like) this, I just just implemented a simple tcp server + my own simple custom binary protocol. The "clients" were typically being run on different machines, so using tcp was good for that purpose.