Visual Studioの「すべての警告をエラーとして扱う...」

Visual Studioでは、[警告をエラーとして扱う]オプションを選択して、警告がある場合にコードがコンパイルされないようにすることができます。私たちのチームはこのオプションを使用していますが、警告として残しておきたい警告が2つあります。

警告を抑制するオプションがありますが、警告として表示したいので機能しません。

警告として扱う2つを除いて、すべてのC＃警告番号のリストを[特定の警告]テキストボックスに入力するのが唯一の方法のようです。

メンテナンスの頭痛のほかに、このアプローチの最大の欠点は、いくつかの警告に番号がないため、明示的に参照できないことです。たとえば、「この参照を解決できませんでした。アセンブリ 'Data ....'が見つかりませんでした」

誰かがこれを行うためのより良い方法を知っていますか？

なぜこれが有用なのかすぐにわからない人のために明確にします。ほとんどの警告がどのように機能するかを考えてください。彼らはあなたが書いたばかりのコードで何かが少しずれているとあなたに言っています。それらを修正するのに約10秒かかり、コードベースをよりクリーンに保ちます。

「廃止」警告はこれとは大きく異なります。時々それを修正することは、単に新しいメソッドシグネチャを消費することを意味します。ただし、クラス全体が古く、数十万行のコードに分散して使用されている場合、修正に数週間以上かかることがあります。あなたはビルドがその間破壊されることを望んでいませんが、間違いなくそれについての警告を見たいと思っています。これは単なる仮説的なケースではなく、私たちにも起こりました。

文字通りの "#warning"警告もユニークです。私は頻繁にしたいそれをチェックするために、私は、ビルドを壊したくはありません。

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つはデバッグまたはリリースとラベル付けされ、他は警告について適切にラベル付けされます。

警告をエラーとして扱います。

まれなケースですが、許容できる警告が表示された場合（つまり、古いメンバーを参照している場合、またはXMLシリアル化クラスのドキュメントがない場合）、＃pragma disableを使用して明示的に抑制する必要があります（オプションで、クリーンなコードがない理由を提供できます）コメントとして）。

このディレクティブの存在により、質問がある場合に誰がこのバージョン違反の「非難」アクションによってこの警告違反を受け入れたかを知ることができます。

「612、1030、1701、または1702以外の警告がコード内に含まれている場合、誰もがコードをチェックインし、ホワイトボードに移動して100回書き込む必要があります。許可されていない警告のコードは再度チェックインしません。 「」

プラグマ警告（C＃リファレンス）

プラグマ警告は、特定の警告を有効または無効にするために使用できます。

http://msdn.microsoft.com/en-us/library/441722ys(VS.80).aspx

根本的な問題は、実際には警告をエラーとして扱うことと、明らかにそうでない場合の組み合わせと、これに違反するチェックインを許可するという明らかなポリシーの組み合わせのようです。あなたが言うように、あなたは警告にもかかわらず仕事を続けることができることを望みます。あなたは無視したいいくつかの警告しか述べていませんが、チームの他の誰かが他のタイプの警告を引き起こした場合、修正するのに同じくらい時間がかかりますか？あなたもそれを無視できるようにしたくないですか？

論理的な解決策は、1）コードがコンパイルされない場合にチェックインを許可しない（つまり、警告を作成した人は、実際にはビルドを壊したため、それらを修正する必要がある）、または2）警告を警告として扱うことです。2つのビルド構成を作成します。1つは警告をエラーとして扱い、定期的に実行してコードに警告がないことを保証し、もう1つは警告としてのみ扱い、他の誰かが警告を導入した場合でも作業できるようにします。