【问题标题】:What level is release/debug applied at in Visual Studio?Visual Studio 中应用的发布/调试级别是什么?
【发布时间】:2012-07-01 14:56:57
【问题描述】:

我目前正处于项目的最后阶段。作为我努力的一部分,我一直在重新组织主要的 MVC 解决方案以使用对预编译库的引用,而不是在一个解决方案中包含 15 个不同的项目。

我的问题与 Release/Debug 开关的应用位置有关。

例如,我的低级库是在调试模式下构建的,而我的主 Web 客户端应用是在发布模式下构建的。

项目是在发布模式(因为这是主应用程序的配置)还是调试模式(因为主应用程序依赖于以调试模式编译的二进制文件)?

【问题讨论】:

  • "将要建项目" 你指的是哪个项目,主应用程序还是库? Visual Studio 的调试/发布设置是针对每个项目的,而不是针对每个解决方案的。
  • 真的有必要把各个项目都拉出来,引用编译好的库吗?你会独立开发这些其他库,还是只会随着主应用程序而改变?它们仅与主应用程序一起使用吗?我出于好奇而问。
  • @Adam - 主要项目。本质上,我是在问“如果主应用程序是在发布模式下构建的,那么其他一切都尊重这一点吗”?
  • @JoshSmeaton - 有些东西已经成熟,不太可能改变,并用于支持其他项目。这些是引用 DLL 的明确候选者。可以说我应该将特定于应用程序的东西保留在解决方案中,但就像我在 OP 中所说的那样,我在一个解决方案中拥有 15 个项目。在解决方案资源管理器中变得非常非常耗时。不开玩笑:)
  • 如果要导航的项目/文件的数量是造成这种情况的原因,请查看生产力工具、Resharper 或 CodeMaid。所有这 3 种方法都可以加快导航大型解决方案的速度。此外,您会发现比 15 个项目大得多的解决方案是常态,我在 ATM 上工作的 3 个项目有 50 多个。

标签: c# visual-studio-2010 compilation release


【解决方案1】:

在您描述的场景中,您的 Web 项目将构建为“发布”程序集,并将依赖于“调试”程序集。引用的原因是“发布”和“调试”程序集(除非使用非默认选项)之间的唯一区别是分别排除或包含调试符号和程序集中 IL 的优化。所以,这是一个完全有效的情况,有一个引用调试程序集的发布程序集,尽管它可能不是你想要的。因为调试程序集中会有更多的 IL(因为它内置了 wirhout 优化)让 JIT 做更多的工作来尝试优化它将在机器上运行的代码,这可能会导致运行时体验不那么优化、速度变慢。

根据您是否对引用的程序集进行数字签名,您可以使用构建后任务将调试编译的引用程序集替换为发布编译的程序集,以用于项目的输出。

可以提出一个论点,即您不应该在用于创建它们的解决方案之外引用调试编译的程序集,作为将 DLL 引用为文件的操作假设(而不是在 IDE 中进行项目引用)是该程序集是它所包含的功能的经过测试的完成版本。

总之,您的项目的编译方式并不依赖于它所引用的程序集的构建配置,但是,如果可能,您应该改为引用这些程序集的发布编译版本。

【讨论】:

  • 长话短说,编译是“发布模式”,但是 JIT 需要做额外的工作来整理调试依赖关系?
  • JIT 将在调试程序集本身上花费更多时间,对调试库的调用将花费更长的时间,在发布程序集中运行的代码应该/将比在调试程序集中运行的代码更快(假设在执行代码上进行苹果对苹果的比较)
猜你喜欢
  • 2010-09-26
  • 1970-01-01
  • 2019-10-22
  • 2011-03-09
  • 2011-07-17
  • 1970-01-01
  • 2016-12-14
相关资源
最近更新 更多