我正在开发一个项目，我需要为Windows创建应用和服务包。我希望服务进程以SYSTEM或LOCALSYSTEM身份运行，以便凭据无关紧要。应用程序前端将由计算机上的任何用户安装和执行。来自前端应用程序的数据将传递给服务 - 很可能是用户选择的目录的路径。启动后，服务将侦听命令，以便在接受上述路径时执行某些操作。
我在.NET平台上使用C＃，我已经考虑分别创建独立服务和独立应用程序，以及创建WCF服务库和宿主应用程序 - 这就像就在我得到的时候。
所有这些方法对于我想要实现的目标来说似乎过于复杂。尝试这样的事情时，现代约会是什么？我愿意并且能够学习前进的最佳方法。
编辑：这被标记为重复。我不是在寻找有关如何与Windows服务进行通信的信息。这是补救措施，而不是我所要求的。我正在寻找能够在正确的轨道上进行验证，如果我没有，我正在寻找建议。我被告知我在正确的轨道上指向命名管道绑定。
答案 0 :(得分：-1)
Windows Service当然是托管WCF的一种选择，尽管它有点像部署的噩梦。这实际上取决于您的环境以及系统管理员的能力和支持，因为我有许多部署Windows服务的客户端，因为您需要管理员权限来安装和更新它，这根本不可行。
控制台应用程序可能听起来像一个糟糕的想法，但是能够将它们放在共享上并运行PowerShell脚本来启动它们的实用性非常引人注目。
但坦率地说，IIS托管在我看来最具优势，因为该产品的设计便于部署和正常运行。您可以在IIS中使用可在Windows服务或控制台中使用的任何传输绑定。
至于绑定本身命名管道在许多企业场景中并不是真正的流行选项，因为它与除.NET之外的任何东西都不兼容。虽然对于二进制文件也是如此，这是性能更高的绑定之一。 WSHttpBinding可能是需要未知调用者的场景中最受欢迎的绑定。 WebHttpBinding是一个有趣的选择，因为它基于HTTP / REST，虽然这需要进一步装饰你的操作，老实说，如果你走这条路，你应该真正使用Web API。