The company with which we are integrating is a door security company that makes RFID cards and door scanners. You scan your card, the door opens and lets you in. They allow 3rd party integration via their websocket server. They post "Events" to their server. "Bob Foobar scanned his card at door reader #14 at 8:12am on 2/26/2018" all in json format. We need to constantly listen for all of those events and log them in our database.

We give our clients two options. We cloud host our service in a multi tenant SAAS environment. But we also allow customers to self-host if they want. If we only had the SAAS option, then this would be a simple solution. Just create a Windows Service that runs on our servers to subscribe to their websocket server. But, for our self-hosted customers, we are hoping to avoid asking them to install a Windows Service. We are looking for other ways to make this happen. But, we also don't want to ask them to open a browser window and keep it open.

I need to subscribe to a remote websocket, and I need to do it in such a way that it's always listening, even w/o user interaction. This isn't a chat type service that is user-centric. We need to always be listening for events as they appear on the remote server.

I've been reading up on System.Net.WebSockets, and I've seen lots of examples. I have built a proof-of-concept as a Windows Service, and it works.

But... is a Windows Service really the only way to always subscribe to the remote websocket server w/o user interaction? What other options do I have? And, is it possible to accomplish this strictly using IIS?

  • Down-votes w/o an explanation are so frustrating. Can't you at least take 20 seconds to teach and explain? Feb 26, 2018 at 19:49
  • I'm guessing because it appears to be an XY question.
    – JimmyJames
    Feb 26, 2018 at 20:02
  • 3
    It's also unclear why you need user interaction to connect a websocket. Most systems are unaware of eyeballs. What exactly is the problem you are having?
    – JimmyJames
    Feb 26, 2018 at 20:05
  • @JimmyJames, the vast majority of tutorials I see on websockets teach how to wet up a web-based chat service. That's not what I want. I need a userless subscription to a websocket server that listens for events w/o having a web page loaded in a browser. Feb 26, 2018 at 20:10
  • So where do you want this to run and what's the point of it?
    – JimmyJames
    Feb 26, 2018 at 20:17

2 Answers 2


I think there are 3 or 4 kinds of process:

  • Applications started by a user
  • Applications started automatically when a user logs in
  • Services started when the O/S boots, before the user logs in
  • (Device drivers)

If you want your process to run:

  • Before a user logs in
  • and after a user logs in
  • and after a user logs out

... then it does need to be running as a ("system") service, instead of as a ("user") application.


  • Run it as a plug-in of an existing service -- in that case, the architecture and administration (e.g. installation) of the plug-in, and its security context, depends on the service (e.g. IIS)
  • Run it as a user application, if you don't mind the user being able to kill it and you don't mind it starting and stopping when the user logs in or out
  • ..or you can write your own system service
    – Ewan
    Mar 1, 2018 at 16:29
  • Yes, when I said "alternatives" I meant "alternatives to the aforementioned running it as a service".
    – ChrisW
    Mar 1, 2018 at 16:31
  • i must be getting old and sleepy
    – Ewan
    Mar 1, 2018 at 16:32

The first problem I see with either the SAAS solution or the client-based solution is how you deal with disconnects. I'm not a websockets expert (far from it) but I don't believe there is anything built in to it to maintain a subscription. I could be wrong but a cursory search didn't turn up anything. If you truly need to capture every message, this is a big issue as you must expect some downtime of either your client and/or the network. Have you considered how you will catch-up on missed messages? When I played around with these a bit, I found that connections were not terribly stable and would drop unexpectedly (it was a while ago: YMMV.) You, will, at the very least need to make sure your client can re-establish itself if you lose the connection.

As far as running it goes, you just need to create a client application. I would provide that to your customers and give them information on how to run it as a service in windows. The whole thing sounds rather flimsy though. Not so much because what you are trying to do but because you have to depend on websockets. I think they can be useful if combined with a proper API that allows you to retrieve information on demand but by themselves, I think you will have issues.

  • I guess you're referring to google.fr/search?q=run+application+as+service using a non-standard (third-party) service control manager.
    – ChrisW
    Feb 26, 2018 at 22:59
  • @ChrisW I'm not sure exactly what you are asking. Can you clarify?
    – JimmyJames
    Feb 27, 2018 at 14:42
  • You wrote, "create a client application ... provide that to your customers and give them information on how to run it as a service in windows". SFAIK you can't run a client application as a service (a service must implement ServiceMain). But 3rd-party s/w may let you do it ... or (googling) I find srvany ... I guess I'm asking, "what exactly are you suggesting, re. information on how to run it as a service?"
    – ChrisW
    Feb 27, 2018 at 14:54
  • The whole topic is kind of kind of moot though if the OP doesn't want a service and won't say why.
    – ChrisW
    Feb 27, 2018 at 15:02
  • @ChrisW Honestly, I would never run something that needs to be up all the time in windows. I assumed any commandline process could be run as a service like how a daemon in *nix. I'm probably wrong here, I'll edit the answer later.
    – JimmyJames
    Feb 27, 2018 at 15:02

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.