在Visual Studio中引用项目而不是开源项目的DLL是否较慢？

Question

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

Answer 1

  

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

默认情况下，如果选择“构建”，则visual studio仅会考虑更改的代码。如果选择Re-Build选项，那么将考虑编译所有内容。

  

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

  

使用项目引用的好处是：

     

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

取自：

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