0

是不是比较慢？有时会出现由开源项目触发的异常或问题，直接访问代码可以让您更深入地了解自己做错了什么。它是否会减慢项目速度，尤其是它是否会增加编译时间？假设没有对项目进行任何更改 - 我认为它不需要每次都重建？

4

4 回答 4

1

假设没有对项目进行任何更改 - 我认为它不需要每次都重建？

默认情况下，如果您选择构建，Visual Studio 只考虑更改的代码。如果您选择 Re-Build 选项，那么将考虑编译所有内容。

它是否会减慢项目速度，尤其是它是否会增加编译时间？

如果慢是指应用程序执行性能，那么不，应该没有任何区别，对于编译时间，是的，它会增加一点（如果没有对参考项目进行任何更改）。如果项目在多个位置被引用并且对项目进行了更改，那么一切都应该经过编译过程以确保一切正常。

于 2012-10-25T09:05:12.473 回答
0

我个人更喜欢让项目本身打开（至少开始时）。只要您不经常清理/构建，构建应该只编译具有更改代码的项目，因此编译速度只有很小的差异。

运行时，假设您打开的版本与 DLL 中的版本相同并且您进行了发布构建，那么速度应该没有真正的差异

也就是说，在我了解发生了什么之后，我通常会切换到 DLL 以避免解决方案资源管理器中的混乱和 VS 中的额外内存使用

于 2012-10-25T09:01:35.983 回答
0

如果您不打算更改开源库中的任何内容。那么这是一个开销。因为每次编译项目时它都会编译。

于 2012-10-25T09:02:53.393 回答
0

一般来说，您应该尽可能使用项目引用。这是来自一篇旧文章，但我相信它仍然适用：

使用项目引用的优点是：

  • 他们在加载了解决方案和项目集的所有开发工作站上工作。这是因为项目文件中放置了一个项目全局唯一标识符 (GUID)，该文件在当前解决方案的上下文中唯一标识了引用的项目。
  • 它们使 Visual Studio .NET 构建系统能够跟踪项目依赖关系并确定正确的项目构建顺序。
  • 它们避免了引用程序集在特定计算机上丢失的可能性。
  • 它们会自动跟踪项目配置更改。例如，当您使用调试配置进行构建时，任何项目引用都引用由引用的项目生成的调试程序集，而它们引用发布配置中的发布程序集。这意味着您可以跨项目自动从调试切换到发布版本，而无需重置引用。
  • 它们使 Visual Studio .NET 能够检测和防止循环依赖。

取自：

http://msdn.microsoft.com/en-us/library/Ee817675%28pandp.10%29.aspx

于 2012-10-25T16:31:43.990 回答