Visual Studioでは、「警告をエラーとして扱う」オプションを選択して、警告がある場合にコードがコンパイルされないようにすることができます。私たちのチームはこのオプションを使用していますが、警告として保持したい警告が2つあります。
警告を抑制するオプションがありますが、警告として表示されるようにしたいので、それは機能しません。
必要な動作を取得する唯一の方法は、警告として処理する2つを除き、すべてのC#警告番号のリストを[特定の警告]テキストボックスに入力することです。
メンテナンスの頭痛に加えて、このアプローチの最大の欠点は、いくつかの警告に番号がないため、明示的に参照できないことです。たとえば、「この参照を解決できませんでした。アセンブリ 'Data ....'が見つかりませんでした」
誰もこれを行うためのより良い方法を知っていますか?
これがなぜ役に立つのかすぐに分からない人のために明確化する。ほとんどの警告がどのように機能するかを考えてください。彼らは、あなたが書いたばかりのコードで何かが少しずれていると言います。それらを修正するのに約10秒かかり、それによりコードベースがよりきれいになります。
「廃止」警告はこれとは大きく異なります。修正することは、新しいメソッドシグネチャを消費することを意味する場合があります。しかし、クラス全体が廃止されており、その使用法が数十万行のコードに散在している場合、修正に数週間以上かかる可能性があります。ビルドがその間壊れることは望ましくありませんが、それについての警告を見ることは間違いありません。これは単なる仮説的なケースではなく、私たちにも起こりました。
リテラル「#warning」警告もユニークです。私はよくwantをチェックインしますが、ビルドを壊したくありません。
プロジェクトファイルにWarningsNotAsErrors
- tagを追加できます。
<PropertyGroup>
...
...
<WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>
注意: 612
および618
は両方とも廃止に関する警告です。違いはわかりませんが、私が取り組んでいるプロジェクトは、廃止618という警告を報告しています。
/ warnaserror/warnaserror-:618
より具体的には、あなたの場合:
/ warnaserror/warnaserror-:612,1030,1701,1702
これにより、カンマ区切りリストの警告を除くすべての警告がエラーとして扱われます。
エラーとして扱っていないという警告を見続けるのはなぜですか?私はこれが望ましい理由について混乱しています-あなたがそれらを修正するかしないかのどちらかです。
2つの異なるビルド/ソリューションファイルが機能しますか、それとも1つをコピーしてから警告/警告レベルを変更するスクリプトが適切でしょうか。おそらく、コンパイラの一部の実行を無効にしたいが、他の実行を継続したいようです。
そのため、さまざまなコンパイラスイッチを使用することをお勧めします。異なるターゲットでこれを行うことができます-1つはデバッグまたはリリースとラベル付けされ、もう1つは警告について適切にラベル付けされます。
私は警告をエラーとして扱います。
まれに、受け入れ可能な警告が表示された場合(つまり、廃止されたメンバーの参照、またはXMLシリアル化クラスに関するドキュメントの欠落)、明示的に#pragma disableで抑制(およびオプションで、そうでない理由きれいなコードを持つことはコメントとして提供できます)。
このディレクティブの存在により、いくつかの質問がある場合にこの警告違反を受け入れた人(バージョン管理の「非難」アクションによる)を見つけることもできます。
「612、1030、1701、または1702以外のコードでコードをチェックインする人は誰でもホワイトボードに行って100回書く必要がある」というルールを単純に持たないのはなぜですか。 '"