我很困惑如何添加/包含/引用涉及 WCF 的服务器和客户端项目所需的一组支持类。
在我的 C# 解决方案中，我有：
服务器项目使用普通引用来包含 WCF 库。客户端项目使用对 WCF 库的服务引用。
我的问题是我有几个实用程序类，它们在使用 WCF 库中包含的对象定义的服务器和客户端项目中都需要。我不想在服务器和客户端项目中放置这些类的两个（相同的）副本——我宁愿只保留一个副本。那建议使用类库，但是引用是如何工作的呢？这个新的类库将有一个对 WCF 库的标准引用，然后服务器和客户端项目都必须依次标准引用这个新的类库。但是，客户项目现在不会有两个不同定义的 WCF 库中包含的数据对象类的定义吗？还应该如何包含这些实用程序类？
使用服务引用方法可以消除使用 WCF 的一些初始麻烦，因为它为您生成代码，从而简化了您在早期 WCF 日子里的生活。但是，随着您越来越习惯于使用 WCF 并且您意识到服务引用实际上在做什么，您开始意识到服务引用方法有时更多的是障碍而不是帮助。
例如，在我的例子中，我有一个由三个不同项目使用的 WCF 服务——两个 C# 项目和一个托管 C++ 项目。每次更新 WCF 服务接口时，我都必须在这三个项目中的每一个中重新生成服务引用。这很快让我很头疼。
此外（并且您遇到了这种情况），服务引用方法仅处理您的 DataContract 类的结构，而不是它们的行为。因此，如果您在服务器端向 DataContract 类添加便利方法，则必须在客户端手动添加该行为，因为它不是通过元数据交换 (MEX) 操作传达的。
就在那时，我偶然发现了这个视频。在其中，Miguel Castro 提出了一个令人信服的案例，以完全避免使用服务引用方法。当你检查他的论点时，它真的很有意义。
根据他的建议，我建议将您的 DataContract 类和对它们进行操作的类放在客户端和服务器都直接引用（无服务引用）的类库中。正如您将在视频中看到的那样，自己编写客户端代码并在 WCF 接口更改时更新它非常简单。
我已经使用这种方法几个月了，我发现该解决方案对于我使用 WCF 的方式比使用服务引用方法要灵活得多。