我需要實現簡單的文件觀察器實用程序。我決定在內部使用FileSystemWatcher的簡單的Windows服務中實現它。目的是監視給定的目錄路徑（或ftp），並在檢查到某些預定義邏輯後，將文件複製到其他任何需要新文件的服務器上。Windows服務或WCF服務
正如我使用的.net 3.5;客戶端建議我使用WCF。我在WCF方面的經驗非常少。
我不知道如何創建WCF服務，它將像WindowsService一樣運行，並且可以部署在Windows服務器上的服務中。
要成爲未來主義者，創建WCF服務而不是Windows服務是一個好主意，否則我應該堅持使用窗口服務。
Windows服務！= WCF
您不能創建就像一個窗口服務功能的WCF服務。WCF服務等待來自第三方的消息並對其執行操作，而Windows服務是一個始終在後臺運行的進程。 WCF試圖解決從服務接口中分離出通信機制（傳輸協議，如Tcp，Http，Named Pipe等）的問題。
文件看守實用
雖然理論上有可能創建一個新的平面文件的WCF綁定「可以」有它的地址設置爲一個文件系統位置，一個不直接在存在。 NET框架。查看MSDN上的Custom Bindings文章，我不會立即明白如何構建文件系統綁定。這些是可用的定義的傳輸選項：
如果通信必須通過文件丟失完成，然後WCF不能解決您的問題。
當WCF可能工作
哪些客戶可能意味着是創建一個WCF端點，做了copy the file to some other server wherever new file comes in after checking some predefined logic，但你仍然希望有一個FileWatcher監控輸入目錄窗口服務。
如果您有多個客戶端需要能夠執行相同的邏輯，然後將輸出發送到其他服務器，那麼創建WCF服務可能是有意義的，否則它在此時過度設計。
您應該選擇最簡單的選項，直到找到需要更改的地方，最簡單的選項是Windows服務。
有一種編碼原則叫做YAGNI（你不需要它），在這種情況下適用於簡單地將某些東西包裝在WCF服務中將無所作爲，但會增加大多數情況下的不必要的複雜性。簡單地說，做最小可行的解決方案，並只在需要時才進行擴展。
PS。如果通過網絡共享使用FileSystemWatcher，請注意其中存在已記錄的問題，您應該使用poll + FileSystemWatcher的組合。關於它的Stack Overflow有很多解釋。
在您的使用案例中，Windows服務更有意義，我認爲這是更合適的解決方案。您需要始終運行並監視目錄的內容，這正是Windows服務非常擅長的用例。
我會考慮與客戶交談，並解釋Windows服務是更適合這種用例的解決方案。另外，windows服務不是老的帽子，他們在那裏正是爲了解決這些類型的用例，而WCF/windows服務是相輔相成的。
這兩個功能都有服務在他們的名字，他們幾乎沒有什麼共同之處。
Windows服務在單臺計算機上不斷運行。
WCF服務是代碼，可以被其他機器遠程調用。
它只是取決於你需要做什麼。 Windows服務和「WCF服務」幾乎沒有什麼共同之處。
這裏的問題是您是否需要HTTP端點。如果你這樣做，你甚至可以在你的Windows服務中託管一個WCF服務來提供這個服務。請記住，WCF僅用作應用程序之間通信的一種方式。
讀你的描述，但它似乎並不像你需要它。