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