在生产环境构建中不启用CODE_ANALYSIS的原因是什么?

7
在生产(发布)版本中启用静态代码分析是否会有性能成本?
我们的CI服务器在C#项目的调试构建上运行代码分析,而发布构建已禁用静态代码分析(即未定义CODE_ANALYSIS)。如果没有理由在生产构建中禁用代码分析,那么我使用调试构建就是浪费时间。
Reflector向我展示,如果禁用代码分析,则< SuppressMessage > 属性会被排除,但我不认为额外的属性会影响运行时性能。这是启用静态代码分析(在Visual Studio 2013中)的唯一影响吗?

我认为你从错误的角度来看待这个问题。代码分析在未经优化的IL(调试版本)上可能会比在经过优化的IL(发布版本)上产生更好的结果。 - user743382
1
当你已经走得足够远,准备构建和部署发布版本到生产环境时,仍然需要修复代码分析中的警告,这可能需要重构大量代码并重新测试更改,这是一种非常低效的方式。性能不是问题。 - Hans Passant
@hvd 这是我最初的想法之一,但我找不到任何证据表明在调试版本和发布版本中进行代码分析会得出不同的结果。你有吗? - Joel V. Earnest-DeYoung
@Hans 我们在编译时运行代码分析,如果在代码分析期间发现任何警告,我们的CI服务器会在部署之前停止构建链,所以不用担心。 - Joel V. Earnest-DeYoung
静态代码分析就是“静态的”。它作为构建过程步骤运行。没有理由在可能运行混淆器的构建上运行该构建过程步骤,而且有充分的理由不这样做。 - Tetsujin no Oni
1个回答

8

启用CODE_ANALYSIS关键字编译时,实际上会存在一些差异。例如,当未启用此关键字时,编译器将从程序集中移除所有的[SuppressMessage]属性(因此,在后续通过命令行运行FxCop时可能会出现消息显示,因为已经移除了抑制项)。如果您的二进制文件安装在内部系统上,那么保留抑制项可能是可以接受的。但有些公司希望从发布给第三方的程序集中删除这些属性(以及其Justification属性中的内容),因为这些属性的存在可能会泄露敏感信息。

DEBUG版本上运行代码分析可能会得到更严格的结果。大多数RELEASE版本的优化可能会导致特定的FxCop规则丢失。优化可能会通过内联来移除私有方法,或者用常量值代替常量定义中的调用。由于它们被移除了,FxCop无法验证这些项目。这是可以预料的。

为获得最佳效果:在Debug版本中运行Code Analysis。为避免信息泄露,请从Release版本中删除CODE_ANALYSIS常量。


答案中的链接已失效。 - ToastyMallows
已更新至网络存档。 - jessehouwing

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接