This is a short summary of differences between WCF and .NET Remoting when they are used to control a Windows service. Complete article is found here: http://www.ikriv.com/dev/dotnet/AspNetCallsWinService/index.php.
Complete code examples for WCF and Remoting are on GitHub. In the heart of these examples is the code to create client and server without config files for WCF and for Remoting. Both use named pipes, since I believe this is a more natural way to handle intra-machine communication than TCP ports.
Here are the main differences:
Interfaces: WCF requires that all interfaces be marked with [ServiceContract] attributes, and all methods be marked with [OperationContract] attribute. Remoting has no such requirement.
Data objects: In WCF data objects may be marked with [DataContract] and [DataMember] attributes, but this is optional. Remoting requires that all data objects be [Serializable]. This in turn leads to problems with ASP.NET Web API that by default does not work with [Serializable] objects as expected. This behavior must be tweaked using special configuration settings.
Security: In WCF ASP.NET-to-windows-service communication works out of the box. In Remoting it requires adding a special “authorizedGroup” attribute. However, WCF requires the client and the server to be able to share memory, which leads to weird security issues when the client and the server run under the same user, but with different UAC elevation levels.
Documentation: In both cases named pipe bindings are neglected compared to their TCP/HTTP cousins, but with Remoting being an older technology, proper documentation is harder to find.
Performance: anecdotal evidence says that WCF performs better. I suspect that it does not matter in most cases where the data is not sent back and forth in bulk.
Size of code: both WCF and Remoting can be setup purely in code, but Remoting seems to require slightly more code. For WCF all participating assemblies, including interfaces, must reference System.ServiceModel assembly. For Remoting interfaces can be designed using only standard system assemblies.
Bottom line: I lean towards recommending WCF, but watch out for those weird security issues.