我需要实现简单的文件观察实用程序。我决定在一个简单的 Windows 服务中实现这一点，该服务将在内部使用 FileSystemWatcher。目的是监视给定的目录路径（或 ftp），并在检查一些预定义的逻辑后将文件复制到新文件进入的其他服务器
因为我使用的是 .net 3.5；客户建议我使用 WCF。我在 WCF 方面的经验非常少。
我不确定如何创建 WCF 服务，该服务的功能类似于 WindowsService，并且可以部署在 Windows 服务器上的服务中。
作为一个未来主义者，创建 WCF 服务而不是 windows 服务是一个好主意，或者我应该坚持使用 windows 服务。
Windows 服务！= WCF
您不能创建一个 WCF 服务，其功能类似于 Windows 服务。WCF 服务等待来自第三方的消息并对其进行操作，Windows 服务是一个始终在后台运行的进程。WCF试图解决将通信机制（传输协议，如Tcp、Http、Named Pipe等）从服务接口中分离出来的问题。
文件观察器实用程序
虽然理论上可以在 WCF 中创建一个新的平面文件绑定，“可以”将它的地址设置为文件系统位置，但在 .NET 框架中并不直接存在。查看 MSDN 上的Custom Bindings文章，对我来说，如何构建文件系统绑定并不是很明显。这些是可用的已定义传输选项：
如果必须通过文件丢弃进行通信，那么 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 仅用作在应用程序之间进行通信的一种方式。
但是，阅读您的描述，您似乎不需要它。