传送程序集 fxcop 中的 .NET [SuppressMessage] 属性
我想知道人们（指公司/开发人员）是否真的关心在运输程序集中拥有 [SuppressMessage] 属性。
在项目文件中创建单独的配置，其中包含发布模式下的 CODE_ANALYSIS，然后在最终构建中将其删除，这对我来说似乎是一种可以避免的开销。
如果不希望这些保留在最终程序集中但仍想在代码中使用它们，最好的策略是什么？ 将它们存储在 FxCop 项目文件中是否有任何优点/缺点？
[我来自 VS2008 Pro+FxCop 1.36，而不是 VS2008 Team System]
I wonder if people (meaning the company/developers) really care about having [SuppressMessage] attributes lying around in the shipping assemblies.
Creating separate configs in the Project files that include CODE_ANALYSIS in Release mode and then yanking it off in the final build seems kind of an avoidable overhead to me.
What'll be the best stratergy, if one does not want these to remain in the final assembly but still want to use them in code ?
and Is there any advantages/disadvantages of storing them in FxCop Project files ?
[I'm coming from a VS2008 Pro+FxCop 1.36, rather than VS2008 Team System]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
仅当编译期间存在 CODE_ANALYSIS 预处理器定义时，SuppressMessage 属性才会添加到您的代码中。 您可以通过查看 Reflector.exe 中属性的定义来验证这一点。 默认情况下，Release 中没有定义它，因此它不会影响生产代码。
通常，我仅在定义了 CODE_ANALYSIS 的程序集的 DEBUG 版本上运行 FxCop。
The SuppressMessage attribute will only be added to your code if the CODE_ANALYSIS preprocessor definition is present during a compile. You can verify this by looking at the definition of the attribute in Reflector.exe. By default this is not defined in Release so it won't affect production code.
Typically, I only run FxCop on DEBUG builds of my assembly where CODE_ANALYSIS is defined.
从长远来看，我认为这并不重要。 由于这是一个属性（实际上是元数据），因此它不会影响代码性能。 话虽如此，请记住，任何使用 Reflector 等反汇编程序的人都可以使用该属性中的信息。
将它们存储在 FxCop 项目文件中的问题是，您必须确保每个人都使用相同的项目文件，并且项目文件始终与项目一起移动（它已签入源代码管理，这意味着您每次都必须将其签出）你想运行 FxCop）。
如果您不想在生产代码中使用 SuppressMessage 属性，则只需在运行 FxCop 的构建中定义 CODE_ANALYSIS 符号。 这确实意味着在调试配置上定义它或添加其他配置。 仅当定义符号时，属性才会被编译到代码中。
从自动化/夜间构建的角度来看，您可以使用定义了符号的配置进行构建，然后构建不带符号的生产版本，或者进行两次构建 - 一个定义了符号，运行 FxCop 来获取违规情况，然后进行另一个构建没有定义的符号。
In the grand scheme of things, I don't think it really matters. Since this is an attribute (effectively meta-data), it doesn't impact code performance. That being said, do remember that the information in the attribute is available to anyone using a disassember like Reflector.
The problem with storing them in the FxCop project file is that you must then ensure that everyone uses the same project file and that the project file always travels with the project (it's checked in to source control, which means you must check it out each time you want to run FxCop).
If you don't want the SuppressMessage attributes in your production code you would need to only define the CODE_ANALYSIS symbol in the build you are running FxCop against. This does mean defining it either on your Debug configuration or adding additional configurations. The attributes will only be compiled in to the code when the symbol is defined.
From an automated/nightly build viewpoint, you can build using a configuration that has the symbol defined and then build the production release without the symbol or do two builds - one with the symbol defined, run FxCop to get your violations, and then another build without the symbol defined.
我们有大量分散的生产代码，但我们并不特别关心。 它不会影响性能，并且在类中拥有一些看起来很糟糕的属性通常会让人有动力在可能的情况下删除它。
We have a ton scattered around production code, and we don't particularly care. It doesn't effect perf, and having some crufty looking attribute in a class often gives motivation to remove it if at all possible.