I've gotten a bit of reader feedback from my article on Secure, Robust IPC in .NET. Scott VanSickle, in particular, wonders why I left out WM_COPYDATA. Well Scott, it simply slipped my mind! Thanks for reminding me about it.
WM_COPYDATA is certainly a viable IPC mechanism -- it's listed in MSDN right alongside all the others I mention.
Indeed, WM_COPYDATA is a bit more elegant (and perhaps even better performing) than DDE messages. Otherwise, they're functionally identical.
The DDE approach may still be more convenient, for applications where you need to interop with the Explorer shell (viz. for reusing existing instances to open documents). For many apps, the only IPC that's needed is the ability to forward command line arguments to the singleton instance (as in my article's sample app). With DDE, these two use cases can be tackled with one technology.
I've also heard some noises that sound like MS working on a cross-process Remoting channel, for Whidbey or Longhorn. I'm not a big fan of .NET Remoting. The baggage is pretty heavy -- both in terms of run-time memory usage and lines of client code -- and the abstraction it provides (ie: making request/response messaging look like an ordinary method call) simply isn't that useful to me. But it's good to hear there may be an official story for IPC -- maybe even useful in a less-than-fulltrust security context? We'll see.
