What Is the Simplest Method of Inter-Process Communication Between 2 C# Processes

Communicate between 2 processes

You have several options:

Using WCF will allow you to switch between bindings easily. So if you have two processes on the same machine you can use a named pipe binding which is a type of inter-process communication. If you later decide to separate processes onto different machines you can just change configuration to, say, tcp binding and everything will continue working
If you are into REST, there will be client-server frameworks, such as as self-hosted ASP NET Web API or Nancy
If it is something dead simple, you can just write to a file and read from a file, combined with a global named mutex to synchronise access
There is also a choice of a memory-mapped file, where one process writes to a file and the other reads from it. It's a bit geeky approach and I have rarely seen this in use.
Or yet another conventional approach is to use a 3-rd party, such as a database or a message queue system

Local Inter-process Communication via TCP Sockets in C#

You are using the wrong constructor.

TcpClient(IPEndPoint)

Initializes a new instance of the TcpClient class and binds it to the specified local endpoint.

What you probably want is this:

TcpClient(String, Int32)

Initializes a new instance of the TcpClient class and connects to the specified port on the specified host.

See TcpClient constructors

Some knowledge: A client needs a free port too. Normally it will binds to a random free port. For a local connection are two sockets required - one for the client and one for the server.

What is the fastest and easiest way to communicate between 2 processes in C#?

Memory-mapped files (MMF) are the fastest method. The problem though, as you point, is in serialization rather than transfer itself. Serialization is necessary for any transport, even MMFs (except the simplest cases when you have simple data records which can be laid out sequentially in memory). XML is not fast - binary serialization of any kind would work much better.

Best and Easiest Method for inter-process communication in large project

From the tags I understand that we are talking about .NET. Perhaps you should try Microsoft WCF. It unifies this issue, abstracting specific inter-process (inter-service) communication technology from actual code. So generally you'll design and write the interfaces that your processes will use to talk to each other and then you'll configure a specific communication technology in XML config file. That is, you have rather clear separation between "what do the processes talk about" and "how is this communication implemented specifically".

WCF supports SOAP, TCP\IP communication, MSMQ etc., you processes can be IIS-hosted web-services, usual Windows services, console applications etc. - all this under unified framework. I think, this is exactly what you are looking for.

C# communication between processes

The answer is simple;

Since you can import any DLL into the script you may create a custom DLL that will implement communication between the processes in any way you desire: shared memory, named pipe, TCP/UDP.

What is the best choice for .NET inter-process communication?

WCF is the best choice. It supports a number of different transport mechanisms (including Named Pipes) and can be completely configuration driven. I would highly recommend that you take a look at WCF.

Here is a blog that does a WCF vs Remoting performance comparison.

A quote from the blog:

The WCF and .NET Remoting are really comparable in performance. The differences are so small (measuring client latency) that it does not matter which one is a bit faster. WCF though has much better server throughput than .NET Remoting. If I would start completely new project I would chose the WCF. Anyway the WCF does much more than Remoting and for all those features I love it.

MSDN Section for WCF

Best way for interprocess communication in two ways between a server and a client

If you don't know anything about communication, pick an off the shelf solution. A Bidirectional WCF channel is a good example. See What You Need To Know About One-Way Calls, Callbacks, And Events for a primer. Read WCF Overview (including all the links!) for an introduction into WCF.

If you are more versed into communications then you should had defined the problem more clearly:

what authentication model is used? Kerberos, certificates, password, none?
intranet or internet?
who's doing the listenning? your own service, http.sys, WCF activation?
and the most fundamental question: syncronous or asynchronous? And I do not mean asyn as an async API, but async as in queued message oriented protocol.