Best Practices: Adding a CLI to Existing Windows Service in .NET / Core

Question

I'm wondering if anyone has any recommendations for the best way to implement a command line interface to an existing Windows service.

Ideally, the following requirements can be met:

• Supports .Net Core and works cross platform
• Is self hosted (ie not a separate executable)
• Is registered globally and available in any terminal (ie. > myApp doThis -please --prettyplease)
• Can be piped through to a web interface for remote terminal access via existing web app
• Is available via terminals on other local network devices

The big requirement is that this works cross platform and is not tied to Windows. Any recommendations are very much appreciated!!!

Answer 1

Questions that feature the phrase "what is the best" typically aren't a good fit for stackoverflow as they're subjective - there may be no right answer to your query, but maybe there will be some good ones.

One option that I've employed several times in the past is to implement something like a simple shell/command prompt, accessed via telnet. You simply open a listening socket (TcpListener) and accept text commands sent to it/write text to it, something like your first day's of programming, with console in and out stream printing. There are bucketloads of examples on the web of simple tcp servers so I won't provide any code here. In terms of your points:

Supports .Net Core and works cross platform

It's tcp based, this is intrinsic

Is self hosted (ie not a separate executable)

Starts when the app starts, hosted by the app, doesn't need any complex IPc

Is registered globally and available in any terminal (ie. > myApp doThis -please --prettyplease)

The firewall is probably the only thing stopping your remote device communicating

Call be piped through to a web interface for remote terminal access via existing web app

html5/web based implementations of telnet exist. Could also make a simple web interface out of it (treat the browser like telnet; Here's little difference between them, they both read and write tcp sockets, just the browser adds more text from the http protocol. You can filter that out and just get the interesting bit the user can vary (the URL))

Is available via terminals on other local network devices

Covered above

The last time I implemented this was on a server that was used by credit card terminals. It already had a listening socket and clients followed a strict protocol, so it was easy to detect when a message didn't match protocol and treat it as a command instead. The system grew to the point where the server was full remotely configurable via a simple telnet interface, new credit card ranges and routings could be added,debug printouts could be enabled and all traffic would be sent to the telnet client, certain card terminals could be monitored etc; it was nothin more than compsci101 stuff of command = streamreader.ReadLine() , if(command == "debug") Global.DebugLoggingStream = tcpWriterStream

It had a web interface too, based on HttpListener, that just provided a nicely formatted list of the most recent errors, some config settings etc.. some stuff is better on a web page in a table than in an 80char column format. Eventually I upgraded this to be more like the terminal; the user could end the URL with a command, the command would be carried out and the result put in an array. Each time the page was served he array was dumped, so it became a sort of command shell in itself, not requiring telnet. I kept the telnet interface because it was good for realtime debugging, watching messages as they happened etc but if you wanted to get really fancy, websockets exists today for that sort of thing.

Another thought struck me; perhaps most of this hard work has been done for you, if you can find ac# implementation of an irc server, paired with a web based irc client, it would provide a way to "chat" with your service (which is pretty much all a command shell is; a human having a text chat with a program)