1

I have a project I am working on where I need to create an app and service package for Windows. I would like the service process to run as SYSTEM or LOCALSYSTEM so that credentials are irrelevant. The application frontend will be installed and executable by any user on the machine. Data from the frontend application will be passed to the service - most likely paths to directories selected by users. Once started the service will listen for a command to do some action while accepting the aforementioned paths.

I'm using C# on the .NET platform and I've looked into creating a standalone service and a standalone application separately as well as creating a WCF service library and host application - that's as far as I've gotten.

All of these methods seem overly complex for what I am trying to achieve. What is modern convention when attempting something like this? I'm willing and able to learn the best method for moving forward.

Edit: This was flagged duplicate. I'm not looking for information on HOW to communicate with a Windows service. That's remedial and not at all what I'm asking. I'm looking for validation that I'm on the right track and if I'm not, I'm looking for suggestions. I've been told that I'm on the right track and pointed towards named pipe binding.

Smitty
  • 1,765
  • 15
  • 22
  • 2
    It sounds like you where already on the right track. – Scott Chamberlain Feb 09 '17 at 22:08
  • Possible duplicate of [How to communicate with a windows service?](http://stackoverflow.com/questions/4451216/how-to-communicate-with-a-windows-service) – IInspectable Feb 09 '17 at 22:49
  • IInspectable - that link really just regurgitates the MSDN sample on creating a Windows Service and interfacing with it. I'm trying to ferret out the most ideal method - more specifically narrowed to either Windows Service or WCF Service – Smitty Feb 09 '17 at 22:55
  • 1
    I agree with @ScottChamberlain - unless you are looking for the extreme bleeding edge of interop performance, you are on the right track. Try using named pipe binding. – hoodaticus Feb 09 '17 at 23:24
  • Thanks, I've seen named pipe binding mentioned elsewhere, I'll check it out. – Smitty Feb 09 '17 at 23:46

1 Answers1

-1

Windows Service is certainly an option for hosting WCF, although it kind of is a deployment nightmare. It really depends on your environment and the capability and support of your system admins as I've had many clients where deploying a windows service, as you need admin rights to install and update it, was simply not practical.

Console applications may sound like a terrible idea but the practicality of being able to drop them on a share and run a powershell script to start them is very compelling.

But frankly IIS hosting has the most advantages in my mind as the product is designed for ease of deployment and up time. And you can use any transport binding in IIS that you can use in a Windows Service or Console.

As for the binding itself named pipe is not really a popular option in many enterprise scenarios as it is incompatible with anything but .NET. Although the same can be said for binary which is one of the more performant bindings. The WSHttpBinding is probably the most popular binding in scenarios that require unknown callers. WebHttpBinding is an interesting option as its HTTP/REST based, although that requires further decoration of your operations and honestly if your going that route you should really be using Web API.

Jason Lind
  • 263
  • 1
  • 2
  • 15
  • Unfortunately, there are multiple problems with your answer. Named pipes are generally unsuitable, not because they only work with .net, but because they are limited to process to process communication on the same machine. Since when are windows services a *deployment nightmare*? And hosting a production service in a console app? Just no. Also, WSHttpBinding is not interoperable and so actually unsuitable for *unknown callers*. To recommend IIS as a default without understanding how the service will be used is also misguided. I could go on. – tom redfern Feb 10 '17 at 10:46
  • IIS isn't really a good fit for what I'm doing. This will be a service that is passed a very minute amount of data from an simple application and then works with files and actually entire volumes behind the scenes. I was messing with WCF but it didn't seem to really be a good fit. I'm looking at traditional windows service and an interfacing application currently. I was shocked that the WCF tutorial from MSDN had me use a console app to self-host my service. Instantly turned me off of that route at least. – Smitty Feb 10 '17 at 18:53
  • Well the tutorial does that because it is by far the easiest deployment paradigm, and particularly isolates what your doing to WCF and just WCF. From your applications perspective it does not matter how your WCF service is deployed, it just cares what binding(s) it exposes its operations on and the address. From what your describing WCF does seem like a great fit for communicating between the Application and your Service. – Jason Lind Feb 11 '17 at 00:42