131

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

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

必要な動作を取得する唯一の方法は、警告として扱いたい 2 つを除いて、すべての C# 警告番号のリストを [特定の警告] テキスト ボックスに入力することです。

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

これを行うためのより良い方法を知っている人はいますか?


これが便利な理由がすぐにわからない人のために説明します。ほとんどの警告がどのように機能するかを考えてみてください。彼らは、あなたが書いたばかりのコードで何かが少しずれていると言います。それらを修正するのに約 10 秒かかります。これにより、コード ベースがきれいに保たれます。

「廃止」の警告は、これとは大きく異なります。それを修正することは、新しいメソッド シグネチャを消費することを意味する場合があります。しかし、クラス全体が廃止され、数十万行のコードに散らばって使用されている場合、修正に数週間またはそれ以上かかる可能性があります。ビルドがそれほど長く壊れることは望ましくありませんが、それに関する警告を表示したいことは間違いありません。これは単なる仮定のケースではありません。これは実際に起こったことです。

リテラルの「#warning」警告もユニークです。チェックインしたいことがよくありますが、ビルドを壊したくありません。

4

9 に答える 9

168

WarningsNotAsErrorsプロジェクトファイルに-tagを追加できます。

<PropertyGroup>
    ...
    ...
    <WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>

注:612618は両方とも廃止に関する警告です。違いはわかりませんが、私が取り組んでいるプロジェクトは、警告618で廃止を報告しています。

于 2009-01-22T05:52:49.140 に答える
14

/ warnaserror / warnaserror-:618

于 2008-12-19T08:51:03.000 に答える
4

またはより具体的には、あなたの場合:

/warnaserror /warnaserror-:612,1030,1701,1702

これにより、コンマ区切りのリストにあるものを除いて、すべての警告がエラーとして扱われます

于 2008-12-19T08:53:32.293 に答える
1

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

まれに、許容できる警告が表示される場合 (つまり、廃止されたメンバーを参照している、または XML シリアライゼーション クラスのドキュメントが欠落している)、#pragma disable を使用して明示的に抑制する必要があります (オプションで、クリーンなコードを持たない理由を提供できます)。コメントとして)。

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

于 2009-01-22T06:31:36.970 に答える
1

エラーとして扱わない警告を表示し続けたいのはなぜですか? なぜこれが望ましいのか、私は混乱しています - あなたがそれらを修正するかしないかのどちらかです。

2 つの異なるビルド/ソリューション ファイルが機能するか、またはスクリプトをコピーして警告/警告レベルを適切に変更します。おそらく、コンパイラの一部の実行をスコークさせたいと思っているようですが、他の実行を続けたいと思っているようです。

そのため、さまざまなコンパイラ スイッチを使用するのが良い方法のようです。異なるターゲットでこれを行うことができます.1つはデバッグまたはリリースとラベル付けされ、他のターゲットは警告について適切にラベル付けされます.

于 2008-11-06T02:21:25.850 に答える
0

「612、1030、1701、または 1702 以外の警告が含まれているコードをチェックインする人は誰でも、ホワイトボードに行って 100 回も書く必要があります」という単純なルールを設けないでください。 」

于 2009-09-30T16:45:46.437 に答える
-2

pragma warning (C# リファレンス)

pragma warning を使用して、特定の警告を有効または無効にすることができます。

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

于 2008-11-24T17:42:31.687 に答える
-4

根本的な問題は、警告が明らかにエラーではない場合に警告をエラーとして扱うことと、これに違反するチェックインを許可するという明らかなポリシーの組み合わせであるように私には思えます。おっしゃる通り、警告が出ても作業を続けられるようにしたいものです。無視できるようにしたいいくつかの警告についてのみ言及しましたが、チームの他の誰かが他の種類の警告を引き起こした場合はどうすればよいでしょうか。それも無視できるようになりたくないですか?

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

于 2008-11-10T18:22:31.837 に答える