我需要实现简单的文件观察器实用程序。我决定在内部使用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仅用作应用程序之间通信的一种方式。
读你的描述，但它似乎并不像你需要它。