我刚刚使用 WCF 的路由服务成功实现了一个 WF4“版本控制”系统。我有一个 version1 工作流服务，我向其中添加了一个新的 Decision 活动并将其保存为 version2 服务。所以现在我有 2 个端点（具有相同的服务合同，即两个服务的所有接收活动都是相同的）和一个检查消息内容的路由器（对象上的“versionId”字符串，我的所有接收都接受为参数）来决定要命中哪个端点。
我的问题是，虽然在没有对服务合同进行任何更改时这可以正常工作，但如何处理从我的服务合同中添加或删除方法并创建 version3 服务的需要？我最初的想法是，当我将服务引用添加到我的客户端时，我使用最新的工作流服务的端点来获取最新的服务合同。然后，在配置文件中，我将连接的端点更改为路由器的端点。但是如果 v1 和 v2 的合同与 v3 不同，这将不起作用。我的代理将拥有 v3 的方法，而忘记所有关于 v1 和 v2 的信息。
关于如何处理这个问题的任何想法？我应该在我的工作流解决方案中创建一个实际的服务合同接口（而不仅仅是在我的接收活动中提供一个 ServiceContractName）？
如果 WCF 合同发生更改，您的客户端将需要了解其他操作以及何时调用它们。我使用了活动书签，它包含 WCF 操作，来自某些应用程序中的持久性存储，通过检查启用的书签并基于此启用/禁用 UI 控件，让客户端应用程序动态地适应工作流。当新操作添加到工作流的新版本时，客户端仍然需要更新。
在 WCF 还很年轻的时候，我听到一些声音认为端点版本控制（对于 Web 服务而言）应该通过使用文件夹结构来完成。我从来没有亲自尝试过，但在我看来，仅仅分析这种策略的后果是一个很好的解决方案。我没有 WCF 的生产经验，但即将使用 .NET 4.0 版（ASP.NET、WCF、WF...）推出一个相当全面的解决方案，在这个阶段我认为使用文件夹结构来分隔版本的端点将是一个很好的解决方案。
这种策略的本质是永远不要更改或删除端点（特定版本）的合同，直到您 100% 确定不再使用它。当您的服务不断发展时，您只需添加新的合同和端点。如果一个人不是应有的结构化开发人员，这可能会导致代码重复。但是通过引入服务外观，重复将是微不足道的
我也经历过同样的情况。您可以通过自定义实现来维护版本。将工作流服务 URL 保存在数据库中。并根据需要调用它们。
您可以通过该 URL 获取客户端调用 WF Service 的信息。
http://rajeevkumarsrivastava.blogspot.in/2014/08/consume-workflow-service-45-from-client.html
希望这可以帮助