SL4 号楼 + RIAServices 应用程序在 VS2010 上运行时间过长
有一个Win7盒子，上面安装了VS2010 Premium。 构建桌面应用程序效果很好。 但我们通过 15 个 SL4 和 21 个桌面项目得到了这个解决方案...构建 SL 部分需要太长时间。这是非常令人恼火的，并且鼓励放弃 TDD，因为每次我运行测试时，msbuild 都会花费大约 3 秒的时间来发现没有任何变化，并且应该跳过该项目。这些项目非常小，没有什么特别的，在我们从 VS2008+SL3 切换之前没有任何问题。 我听到人们抱怨 VS2010 的总体速度，但对 SL4 的构建时间却一无所知。 有人遇到同样的问题吗？有解决方法吗？
Got a Win7 box with VS2010 Premium installed on it.
Building desktop apps works just fine.
But we got this solution with 15 SL4 and 21 desktop projects... Building the SL part of it takes too long. This is very irritating and encourages to drop TDD since every time I run a test it takes ~3 seconds for msbuild to find out that nothing changed and the project should be skipped. The projects are very small and there's nothing fancy in them and we hadn't any problems before we switched from VS2008+SL3.
I've heard people complaining abound VS2010 speed in general, but nothing about SL4 build time.
Is anyone experiencing same problems and is there any workaround for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
需要那么多项目吗？根据经验，越少越好。你说这些项目非常小，这对我来说意味着你可能不需要那么多。
不要使用它来管理依赖关系（避免循环）。如果您尝试管理“开发单元”或逻辑分组，请改用命名空间。
物理/项目分离有利于将测试代码排除在生产代码之外，并管理部署单元，但在您从中获得某些东西之前不要将其分离。
Patricks Smaccia 写了一篇好文章 何时以及何时不创建程序集。
解决问题的另一种方法是将您的解决方案分解为多个解决方案，并且
使用对其他解决方案生成的 dll 的引用。这样，您一次只能构建其中的一部分。如果您需要同时处理许多 dll，这会很不方便，但它表明您的代码设计可能存在问题。
这篇关于超速与慢速的文章与许多项目建立联系也可能有所帮助。
Do you need that many projects? As a rule of thumb, less is better. You say that the projects are very small, that would be an indication to me that you probably don't need that many.
Don't use it for managing dependencies (cycle avoidance). If you're trying to manage 'units of development' or logical groupings, use namespaces instead.
Physical/project separation is good for keeping test code out of production code, and managing units of deployment, but don't separate it until you're getting something out of it.
Patricks Smaccia wrote a good article on when and when not to create assemblies.
Another way to tackle the problem is to break your solution up into multiple solutions, and
use references to the dlls produced by the other solutions. That way, you only build part of it at a time. If you need to work across many dlls at the same time, this is inconvenient, but it's a sign that something is likely to be wrong with the design of your code.
This post on speeding vs.net up with many projects may also help.