I want to split a C++/CLI application on two parts :

1. Communication Part, with I/O + logging on text file :

3 COM Ports, 2 sockets and 1 log file

2. UI Part, to handle the data received from COM Ports, sockets etc...

For the moment, my application is constantly reading from all COM Ports (with some writing when needed), communicating with 2 servers (sending and receiving) and logging all data received from these modules. The UI is also pretty complex, but it's not relevant for my problem.

Now, I want to separate the communication parts of the program, mostly because of the limitations of the COM ports (1 connection at the same time), to be able to use them on multiple programs. The communication part must be multithreaded so it can communicate with all the modules, and run all the time (as a service ?).

I read about WCF (because this application was made with .NET Framework), but I'm not sure about this solution : It should run on a low configuration (Intel Atom @1.66GHz, 2GB RAM, Windows XP Embedded, .NET Framework 4.0).

Can I try to learn WCF to work something out, or should I find another solution because of the low configuration ? Ideally, I want to build a program that will be able to trigger some events to the UI part.

2 Answers 2


I'm currently working on a complex piece of software that seems similar to yours that uses WCF rather successfully. When the WCF application is run outside of a web server environment its called self hosting, and I suggest you avoid all the service reference generation tools that Visual Studio provides and configure your server and client manually. It's much easier to maintain and once you get a configuration that works for you its pretty simple.

However, if you do have performance concerns (which would make sense given your hardware) and seeing that half of your application is C++, I'd recommend named pipes. Named pipes have been around for a while, and in Windows they are treated by the OS similar to an in-memory file stream that both processes can read and write to, so they are pretty quick.

To get the best of both worlds (or a compromise of both, depending on your viewpoint ;)) WCF provides a named pipe binding, though I've never used it.

Also note this question has been asked before:



  • Thanks for the advice, I will try the WCF "solf hosting" solution with only one SerialPort module, on Single ConcurrencyMode and Single InstanceContextMode to see what I get from that ! Oct 18, 2016 at 14:16

If it is going to be the one computer you should not use WCF, WCF is powerful but complex. I would rather think of isolating the hardware communication code in a DLL assembly that could have separate classes for different communication hardware, all implementing the same interface.

Then just have your GUI create objects based on a configuration file (like 3 different COM ports with its settings) and talk to the interface of each instance.

The ability to distribute the data acquisition modules may be tempting though, in which case WCF could be for you after all. It scales nicely, it can use low-level TCP over a LAN and http over a WAN just the same, all handled for you.

It does named pipes also if you wish (for communication on the same machine) but in my experience the performance gain over TCP is negligible.

  • Even if his hardware is in separate assemblies, multiple processes cannot access comports simultaneously. Oct 17, 2016 at 16:59
  • @whatsisname With one or more dll assemblies in addition to your gui assembly you would not have multiple processes. In any case, no more than one class instance would be bound to any COM port. Oct 17, 2016 at 17:46
  • The OP said he wants to use his hardware layer across multiple processes. Oct 17, 2016 at 19:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.