Separate console project / windows service for external communication to another system

We’ve got our basic infrastructure in place for the Web / React side. Everything is working great.

The second phase of our architecture is going to be a stateful, TCP connection to state switches (in various states across the US) to run various queries in a very specific format. This has all been written before in .NET Framework, and we are about to begin the re-write using MQ + ServiceStack for message passing (we were using Hangfire before to do message passing, which wasn’t the best option but the easiest).

The legacy application is a windows service that runs on a Windows Server 2008 box (using Topshelf). It maintains a connection to the state switch, receives messages from the UI side and forwards it to the switch. Then receives responses from the state switch and forwards it back to the UI side (a perfect use case for MQ).

What I don’t fully understand is how AppHostBase integrates with this. I know in my WebAPI project it is a completely self contained .NET Core (I’m using SS 5.0) pipeline. How does this work with a shared service (IE one service that hosts the UI, and one backend service that communicates via a shared MQ model)? Is there a recommended best practice?

The way I envision it is having one MyProject.Web and one MyProject.StateServer - with possibly a shared AppHost in a MyProject.Logic or MyProject.Common project. Can SS 5.0 run in a windows service on a Windows 2008 box? Is there a better way via message passing?

Not exactly sure what the question is, but yeah you can run ServiceStack in a Windows Service, we have a Windows Service Template in ServiceStackVS with an updated v5 version at winservice-netfx.

Also checkout the Service Gateway for making in-process / out-of-process calls between ServiceStack Services.

Exactly what I needed. This is interesting, with out-of-process calls I could potentially use that as a message passing mechanism.

So is the windows service only for .NET Framework?

Yeah, the Windows Service project template requires .NET Framework / Windows.