人々 (会社/開発者を意味する) は、出荷アセンブリに [SuppressMessage] 属性が横たわっていることを本当に気にかけているのだろうか。
リリース モードで CODE_ANALYSIS を含むプロジェクト ファイルに個別の構成を作成し、最終ビルドでそれをヤンクすることは、回避可能なオーバーヘッドのように思えます。
これらを最終的なアセンブリに残したくないが、それでもコードで使用したい場合、最善の戦略は何でしょうか? それらをFxCopプロジェクトファイルに保存することの利点/欠点はありますか?
[VS2008 Team System ではなく、VS2008 Pro+FxCop 1.36 から来ています]
SuppressMessage属性は、コンパイル中にCODE_ANALYSISプリプロセッサ定義が存在する場合にのみコードに追加されます。これは、Reflector.exeの属性の定義を確認することで確認できます。デフォルトでは、これはリリースで定義されていないため、製品コードには影響しません。
通常、FxCopは、CODE_ANALYSISが定義されているアセンブリのDEBUGビルドでのみ実行します。
大まかに言えば、あまり重要ではないと思います。これは属性 (事実上メタデータ) であるため、コードのパフォーマンスには影響しません。そうは言っても、アトリビュート内の情報は、Reflector のようなディスアセンバーを使用しているすべての人が利用できることを覚えておいてください。
それらを FxCop プロジェクト ファイルに保存する際の問題は、全員が同じプロジェクト ファイルを使用し、プロジェクト ファイルが常にプロジェクトと共に移動することを確認する必要があることです (ソース管理にチェックインされているため、毎回チェックアウトする必要があります)。 FxCop を実行したい)。
運用コードで SuppressMessage 属性が必要ない場合は、FxCop を実行しているビルドで CODE_ANALYSIS シンボルを定義するだけで済みます。これは、デバッグ構成で定義するか、追加の構成を追加することを意味します。属性は、シンボルが定義されている場合にのみコードにコンパイルされます。
自動/ナイトリー ビルドの観点からは、シンボルが定義されている構成を使用してビルドしてから、シンボルを使用せずに製品リリースをビルドするか、2 つのビルドを実行します。シンボルが定義されていません。
大量の製品コードが散らばっていますが、特に気にする必要はありません。これはパフォーマンスには影響しません。また、クラスに見栄えの悪い属性があると、可能であればそれを削除する動機になることがよくあります。