在Windows上為其他應用程序創建長期服務器

Question

我已經研究過COM服務器和Windows服務，但是我不確定最適合我的目的或方法。 我想要的是可以無限期地啟動和運行的對象對象，以便其他進程或應用程序獲取對該對象的引用（或向服務器發出請求）以修改或查詢其狀態。

服務器本質上是一個應用程序，它通過串行端口處理到設備的命令並維護設備的內部狀態。

我現在具有用C＃編寫的設備通信和持久性功能，可以在每個進程的基礎上創建和運行它，但是顯然我希望它實例化一次並獨立於其他進程運行。

我讀過的COM教程只是讓我感到困惑，因為我不確定這是否是我想要的，我希望有更多的.Net方式可以做到這一點。

任何幫助將不勝感激！

Answer 1

這似乎很適合Windows服務。 我應該說我不是.net程序員，但我知道您可以使用.net創建服務。 只要您知道可以使用.net來操作串行端口，您就應該很好。

-don

Answer 2

您的要求有點矛盾-如果服務器必須無限期地運行，而不管是否有要服務的客戶端，並且必須在所有客戶端之間共享該進程，而不管它們在哪個會話中運行，則Windows Services是要走的路。

如果要僅在有客戶端的情況下運行服務器，並且可能（或不希望）這些客戶端共享同一服務器進程，則可以選擇COM Out Of Process Servers。

如果是COM，則必須使用DCOM與服務器進程進行通信。 如果是服務，則可以使用DCOM，命名管道，RPC或某些其他IPC機制。

但是，如果您希望用C＃編寫服務器代碼，DCOM似乎是一個奇怪的選擇-可以用C＃創建DCO​​M服務器，但這確實很尷尬。 正如Kevin指出的那樣，WCF / WAS / Remoting可能是更簡單的選擇。 但是請記住，與本地COM服務器或服務相比，這種解決方案幾乎必然會顯着增加內存消耗的開銷。 如果要在客戶端計算機上安裝此軟件，那么我將首選本機解決方案。

Answer 3

您似乎要問兩件事-

1. 一種在Windows上托管長期運行的持久性應用程序的方法，該應用程序將通過串行端口與某些設備或其他設備打交道。
2. 一種從其他應用程序與該應用程序通信的方式。

Windows Service是第一個很好的解決方案。 Windows服務充當您的自定義邏輯的應用程序宿主。 它通過通用的UI和API為您提供啟動/停止以及輕量級的監視和配置功能。 使用C＃構建Windows服務很容易。 通過命令行，應用程序和GUI工具輕松啟動和停止Windows服務。

將WCF視為主要的通信接口。 WCF可用於構造Windows服務公開的外部接口。 如果要從.NET或HTTP客戶端（REST或SOAP）連接到應用程序（服務），則WCF將為您工作。

COM ....您對於COM適用的位置感到困惑，是由於COM將接口機制（IDispatch，IUnknown等）與托管+生命周期模型（本地服務器，Inproc服務器，遠程服務器，根據要求自動啟動等）。 COM中的托管和生命周期功能可以正常工作，但是它總是非常苗條。 很難知道哪些服務正常運行了多長時間。 難以按需啟動和停止。

在這種情況下，COM與WCF一樣，主要是作為通信接口。 如果要使用基於組件的界面連接到服務，COM可能是Windows服務托管的很好補充。

COM和WCF（REST或SOAP）不是互斥的，實際上許多應用程序都公開了多個接口。 您可以選擇做一個，也可以做另一個，或者兩者都做。 沒有錯誤的答案，這取決於您的要求。

如果這樣做的話，我將使用Windows服務，並且還將公開該服務的COM接口， 如此處所述 。 Windows Service負責生命周期和托管內容。 然后可以通過COM（實際上是通過任何編程或腳本語言/環境）訪問該服務。 Javascript，VB6，Excel或OFfice，Python，Perl等

我還要考慮從服務公開WCF接口。 這也將允許任何REST客戶端進行連接。 將WCF視為無線電話，將COM視為固定電話。 有時您只想要一個。 有時您想要兩者。

Answer 4

我將為此構建一個Windows Communication Foundation（WCF）服務，並使用可用的許多綁定之一將其公開。 您可以通過HTTP / SOAP，HTTP / REST，TCP / Binary，MSMQ等通過同一服務公開它。 如果您使用Windows 2008，則可以通過Windows激活服務（WAS）對其進行激活。 如果您有其他Windows操作系統，則應編寫一個Windows服務，該服務可以在服務控制管理器（SCM）中注冊。 這里有很多選擇，但我絕對會傾向於使用WCF創建服務。 WCF為您提供了很多“管道”。 無需重新發明所有這些。 希望這可以幫助。