2014-03-05 19 views
4

在生产(发布)版本中启用静态代码分析时是否存在任何性能成本?任何不在生产版本中启用CODE_ANALYSIS的理由?

我们的CI服务器在C#项目的调试版本上运行代码分析,而发布版本禁用静态代码分析(即未定义CODE_ANALYSIS)。如果没有理由在生产版本上禁用代码分析,那么我会在调试版本上浪费时间。

反射器显示SuppressMessage属性被排除,如果代码分析被禁用,但我不希望额外的属性影响运行时性能。这是启用静态代码分析(在Visual Studio 2013中)的唯一影响?

+0

我认为你是从错误的角度看待这个问题。代码分析可能会对未优化的IL(调试版本)产生比优化的IL(发布版本)更好的结果。 – hvd

+1

当你已经足够准备构建发布版本并将其部署到生产环境中时,仍然需要修复代码分析中的警告,这些警告很可能需要对代码进行重要的代码重构和重新测试,这是一种非生产性的方式去做吧。 Perf不是问题。 –

+0

@ hvd这是我原来的想法的一部分,但我找不到任何证据表明代码分析在调试与发布构建中给出了不同的结果。你可以吗? –

回答

6

在启用CODE_ANALYSIS编译关键字,例如,当the compiler will remove all [SuppressMessage] attributes from the assembly when it is not enabled有实际差异(且因此可能引起消息显示当你在命令行以后运行的FxCop,由于镇压已被删除)。如果你正在内部系统上安装你的二进制文件,那么可以把压制留在二进制文件中。一些公司希望他们从发布给第三方的程序集中移除,因为这些属性(以及对称属性的内容)的存在可能会泄露敏感信息。

当在DEBUG构建运行代码分析你可能会得到严格的结果,出现在大多数RELEASE构建可以导致迷路具体的FxCop规则一定的优化。优化可能会删除私有方法(通过内联),或者用常量替换对常量的调用,而不是定义常量。 FxCop不可能验证这些项目,因为它们已被删除。这是可以预料的。

为获得最佳效果:在调试版本中运行代码分析。要获得最少信息披露,请从发布版本中删除CODE_ANALYSIS常量。

+0

关于未使用的代码优化的好处。 –

相关问题