One solution would be to publish the information via UDP. Open a specific port for broadcasting, send your data. There is nothing else to do on the provider/server side.

On the client side, open the same port for receiving.

The only downside that I am aware of with this method is that if you miss the broadcast message, you will never see it again. There is no guaranteed delivery.

One upside is that you can have unlimited clients with no additional overhead for the server.

Microsoft has a working example using the UDPClient class.

If you need guaranteed delivery, you can use (among other options) the TCPListener class for your server. You will have to use the TCPClient class for the client. This technique will (more or less) recreate a web server and clients. Writing a RESTful interface would be easier.

One downside is that every client opens a connection (more overhead) to your server.

You might be best served by letting the apps pull the information rather than pushing it out — that is a much simpler model as all you need to do is expose an API. The default choice in 2014 is probably an RESTful ASP.NET web api but there are tons of options depending on what you are doing.

As for the push model, MSMQ is a pretty raw tool but it is usable. You might want to look at something like rabbit MQ which is a bit more feature-complete and has a pretty handy pub/sub model.

The bottom line is that there are lots of ways to solve this problem — the best way really depends in specific requirements here.

SignalR might be a good candidate if you don’t need guaranteed delivery, and you’re simply looking to periodically send relatively small amounts of data to/from N* clients and servers (e.g. real-time dashboard, instant messaging, multiplayer game, etc…). It can also scale quite well using backplanes (currently supports Redis, Azure Service Bus, SQL Server, or writing your own).

While SignalR is focused towards ASP.NET development (it abstracts the implementation of WebSockets), you can also use it in non-web applications (i.e. WinForms, WPF, Windows services, etc…).

Plus, SignalR operates over standard HTTP/S ports (80, 443), so you typically don’t need to create firewall exceptions to get things talking correctly.

Another bonus is that you can have two way communication between clients and/or server(s).

Here’s a few links you might find useful:

• Using SignalR in WinForms and WPF
• Microsoft Virtual Academy – SignalR Courses

I’ve been using Rebus which makes it pretty simple to push messages between applications. It is a .NET library that sits as a layer on top of an underlying transport layer, which could be MSMQ, RabbitMq, or something else.

It does support publish/subscribe. In the case of MSMQ, this is simply implemented that Rebus handles publishing the message to multiple queues. Rebus just needs somewhere it can store a configuration about which subscribes have subscribes to which types of messages.

If you want to step up, you can use NServiceBus, which is a paid product. But I have no experience with that. But it should be easy to migrate an app from Rebus to NServiceBus.

Whether it’s applicable to your specific scenario is a different question entirely, but writing to a text file and reading it from the other applications is probably the ‘simplest’ way to transfer data.

For windows .net processes to pipe data between themselves they can do so in different ways using WCF using transport layers such as http or named pipes.

Good tutorial for this:
http://tech.pro/tutorial/855/wcf-tutorial-basic-interprocess-communication

Another question you may find helpful: https://stackoverflow.com/questions/7353670/wcf-named-pipe-minimal-example