Along with garbage collection, another element of the .NET wave that I always thought wasn't entirely thought out, and perhaps rushed to market, was .NET Remoting. There are just so many things about it that seem wrong (not the least that it has a relatively short lifespan before it is superceded by Indigo), and it seemed to be a downgrade from the so-called .dll hell of DCOM/COM+. Not only was it lacking many of the historic enterprise features of COM+ (even seemingly critical features like native authentication and encryption), but the performance was deficient compared to legacy communications technologies, and little quirks like each channel being unidirectional just seemed absurd.

Thankfully, the performance issue has been improved dramatically for same-machine communications with the addition of a new communications channel called IpcChannel. Using classic named-pipes, IpcChannel has demonstrated dramatic speed improvements even over the binary TcpChannel. If you've properly configured remoting declaratively in your config file, it's a simple change to switch to IpcChannel where both ends of the conversation exist on the same logical machine. IpcChannel even lets you specify an Access Control List (ACL) to limit who can connect, which makes sense as authentication and authorization is a native feature of named pipes.

Couple this with the new, easy to use authentication and encryption of .NET Remoting in 2.0 and it has turned into a pretty nice out-of-the-box solution.