我们的团队开始害怕更新解决方案中的服务引用，因为这需要5分钟以上的投资。Visual Studio的web服务器中的所有内容都是本地主机。
我的问题是，如何调试这个问题？它一旦结束就可以正常工作，但长时间的延迟太疯狂了。如果我有一个线索去哪里看，也许我可以解决这个问题。
使用VS2012时，我遇到了同样的问题：仅更新一个服务引用就花了将近10分钟的时间。我只是设法通过以下方式重新添加服务来解决这个问题：
- 删除服务引用
- 右键单击"服务引用"，然后选择"添加服务引用"
- 单击"发现"（在我的情况下是必需的，其他人可能会有所不同）
- 在"服务"下选择要添加的服务
- 为服务提供一个名称（位于底部的"命名空间"下）
- 按"高级"
- 取消选中"重用引用程序集中的类型"，然后按"确定"
- 按"确定"添加服务参考
对我来说，类型的重新使用是一个大问题：现在没有检查，新的更新只需要几秒钟。由于我在其他地方找不到这个解决方案，我想我应该把它发布在这里，以防其他人遇到类似的问题。
由于不断刷新，.soo文件很可能变得荒谬。您可以通过检查来源来对此进行检查。如果是这种情况，您可以删除.soo并更新引用。您可能需要进行备份，以防忘记其他用户设置。
另一种选择是服务的WSDL变得太大了，你必须咬紧牙关。
如果你想减少影响，让服务人员通过一个鲜为人知的秘密——计划——来敲定合同老实说，糟糕的计划通常是VS中出现许多问题的根本原因。
我注意到在Visual Studio中使用svcutil而不是Add Service Reference会缩短生成时间，尽管有时生成的代码略有不同（稍后会详细介绍）。
在工作中，我们有一个WCF服务，由大约100个服务操作和100个服务契约组成，在VisualStudio2012中从该服务公开的WSDL开始生成代理大约需要7分钟。然后我尝试使用svcutil（没有任何选项），生成只花了大约2分钟。
我必须添加一些选项来匹配服务参考中配置的相同特性（/enableDataBinding、/serializable、/namespace:*,myns、/syncOnly和collectionType:System.ComponentModel.BindingList'1），使用此选项，生成时间增加到3分半钟。总的来说，代理生成的速度不是数量级的快，但至少生成时间应该减半。
根据我的经验，这两种生成方法有一些不同之处，我想指出：
-
Visual Studio生成
datasource文件（Visual Studio在向Windows窗体项目添加对象数据源时生成的文件，另请参阅此SO线程）；svcutil没有生成它们的选项。这应该不是一个大问题，因为第一次需要数据绑定到约定时，文件应该由Visual Studio生成。顺便说一句，如果代理是在单独的程序集中编译的，则引用项目无法重用生成的datasource文件，因为它们不包括在程序集中，而且无论如何都会重新生成。 -
服务契约的
ConfigurationName属性可能不同，这显然是因为两种生成方法在生成属性值时对目标命名空间的考虑不同。这在我们的情况下是一个问题，因为我们不使用生成的app.config。然而，这可以通过更改app.config以匹配新值或通过（自动）更改生成的代理源中的ConfigurationName属性来轻松管理。 -
svcutil不会用属性Browsable(false)修饰ExtensionData属性——如果（像我们一样）在Windows窗体中使用数据契约作为数据绑定的源，这可能会成为一个问题，因为现在所有网格都将为ExtensionData获取一个额外的列。与前面的打嗝一样，这可以通过使用类似sed的工具添加属性来处理（例如，我使用了这个答案中包含的PowerShell片段）。
我刚才也遇到了同样的问题，更新我的服务引用大约需要10-15分钟，有时无法更新。我很沮丧，最后我删除了引用，然后又添加了一次。现在一切都很好。
因此，我建议您删除引用并再次添加它，让我们看看
在更新Web引用时遇到缓慢问题。我对时代感到疯狂。超过1小时。
一些同事告诉我添加我的工作区路径以从Windows Defender中排除，这就解决了我的问题。