我有一个项目，我正在研究如何为Windows创建应用程序和服务包。我希望服务进程作为SYSTEM或LOCALSYSTEM运行，以便凭证无关紧要。应用程序前端将由机器上的任何用户安装并执行。来自前端应用程序的数据将传递给服务 - 很可能是用户选择的目录路径。一旦开始，服务将听取命令在接受上述路径的同时执行一些操作。创建Windows应用程序和服务包的理想方法是什么？
我在.NET平台上使用C＃，我已经研究过创建独立服务和独立应用程序以及创建WCF服务库和主机应用程序 - 就我所知。
所有这些方法似乎都过于复杂，我试图实现。尝试这样的事情时，现代会议是什么？我愿意并能够学习推进前进的最佳方法。
编辑：这被标记为重复。我不在寻找如何与Windows服务进行通信的信息。这是补救，而不是我所问的。我正在寻找确认我正走在正确的轨道上，如果我没有，我正在寻找建议。我被告知我在正确的轨道上，并指向命名管道绑定。
Windows服务无疑是托管WCF的一种选择，虽然它是一种部署噩梦。这实际上取决于您的环境以及系统管理员的能力和支持，因为我已经有很多部署Windows服务的客户端，因为您需要管理员权限来安装和更新它，这实际上并不实际。
控制台应用程序可能听起来像一个可怕的想法，但能够将它们放在共享上并运行PowerShell脚本来启动它们的实用性非常有吸引力。
但坦率地说，IIS托管在我看来最具优势，因为该产品的设计便于部署和延长时间。您可以在IIS中使用任何可以在Windows服务或控制台中使用的传输绑定。
至于绑定本身，命名管道在许多企业场景中并不是一个真正流行的选项，因为它与.NET以外的任何东西都不兼容。尽管对于二进制也是如此，这是更高性能的绑定之一。 WSHttpBinding可能是需要未知呼叫者的场景中最流行的绑定。 WebHttpBinding是一个有趣的选择，因为它基于HTTP/REST，尽管这需要进一步装饰你的操作，并且诚实地说，如果你走这条路线，你真的应该使用Web API。
不幸的是，你的答案有多个问题。命名管道通常是不合适的，并不是因为它们只与.net协同工作，而是因为它们仅限于在同一台机器上处理通信。从什么时候开始Windows服务*部署噩梦*？并在控制台应用程序中托管生产服务？就是不行。此外，WSHttpBinding不可互操作，因此实际上不适合*未知的呼叫者*。建议将IIS作为默认设置，而不理解服务将如何使用也是错误的。我可以继续。 –
IIS并不适合我在做什么。这将是一个服务，它从一个简单的应用程序中传递非常少量的数据，然后在后台使用文件和实际上整个卷。我搞乱了WCF，但它似乎并不适合。我正在研究传统的Windows服务和接口应用程序。我很震惊，MSDN的WCF教程让我使用一个控制台应用程序来自我托管我的服务。至少立即将我从这条路线中解放出来。 – Smitty
那么这个教程是这么做的，因为它是迄今为止最简单的部署范例，特别是将你对WCF和WCF的做法隔离开来。从您的应用程序角度来看，您的WCF服务的部署方式并不重要，它只关心其公开其操作的绑定和地址。从你描述的WCF看起来非常适合在应用程序和你的服务之间进行通信。 –
听起来像你已经走上正轨。 –
可能重复的[如何与Windows服务进行通信？]（http://stackoverflow.com/questions/4451216/how-to-communicate-with-a-windows-service） – IInspectable
IInspectable - 该链接真的只是反刍有关创建Windows服务并与之连接的MSDN示例。我试图找出最理想的方法 - 更具体地缩小到Windows服务或WCF服务 – Smitty