我有一個項目，我正在研究如何爲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