linq - LINQ ステートメントをデバッグする方法

Question

Linq to objects ステートメントがあります

 var confirm = from l in lines.Lines 
 where (l.LineNumber == startline.LineNumber) || (l.LineNumber == endline.LineNumber) 
 select l;

確認オブジェクトは System.Linq.Enumerable.WhereListIterator`1.MoveNext() で 'Object Null or Not A Reference' を返しています

クエリの結果が空の場合、空の列挙子が返されます。ステートメントに null オブジェクトがないことは事実です。LINQ ステートメントをステップ実行して、落ちている場所を確認することはできますか?

編集私がnullオブジェクトがないという事実を知っていると言ったとき、私は嘘をついていたことが判明しました:[、しかし、答えは「あなたは本当にできない」と仮定していますが、疑問は残ります

LINQPad は良いアイデアです。LINQ を独学するために使用しましたが、デバッグ/スラッシュアンドバーンスタイルのツールとして再び検討する可能性があります。

score 31 · Accepted Answer

はい、確かに linq クエリの途中で実行を一時停止することは可能です。

ラムダ式を使用して linq をクエリスタイルに変換し、デバッグする linq 内のポイントの後に自分自身を返す Select ステートメントを挿入します。いくつかのサンプルコードはそれをより明確にします -

        var query = dataset.Tables[0].AsEnumerable()
            .Where (i=> i.Field<string>("Project").Contains("070932.01"))
 //         .Select(i =>
 //         {return i;}
 //           )
            .Select (i=>i.Field<string>("City"));

次に、コメント行のコメントを外します。{return i;} が独自の行にあることを確認し、そこにデバッグポイントを挿入します。この選択は、長くて複雑な linq クエリの任意の場所に配置できます。

score 29 · Accepted Answer

VS からデバッグできるかどうかはわかりませんが、LINQPadは非常に便利です。LINQ クエリの各部分の結果をダンプできます。

score 18 · Accepted Answer

whereLINQ ステートメントの句で式にブレークポイントを設定できるはずです。

この例では、次のコードセクションの任意の場所にカーソルを置きます。

(l.LineNumber == startline.LineNumber) || (l.LineNumber == endline.LineNumber)

次に、を押すF9か、メニューまたはコンテキストメニューを使用して、ブレークポイントを追加します。

正しく設定されている場合、LINQ ステートメント全体ではなく、上記のコードのみがエディターでブレークポイントの書式設定を持つ必要があります。ブレークポイントウィンドウで確認することもできます。

正しく設定すると、クエリの上記の部分を実装する関数で毎回停止します。

score 15 · Accepted Answer

私は、2010 年に Simple-Talk.com ( LINQ Secrets Revealed: Chaining and Debugging ) で公開されたこの質問に対処する包括的な記事を書きました。

Visual Studioの外部ツールとして、LINQPad (前述の OwenP が言及) について説明します。その異常な Dump() メソッドに特に注意してください。これを LINQ チェーンの 1 つ以上のポイントに挿入して、驚くほどクリーンで明確な方法で視覚化されたデータを確認できます。非常に便利ですが、LINQPad は Visual Studio の外部にあります。コードのチャンクを LINQPad に移行するのは現実的ではない場合があるため、Visual Studio内で使用できるいくつかの手法も紹介します。

(1) 記事で紹介した Dump() 拡張メソッドへの呼び出しを挿入して、ロギングを許可します。Bart De Smet の有益な記事LINQ to Objects – Debuggingの Watch() メソッドから始めて、視覚化を強化するためにいくつかのラベル付けと色付けを追加しましたが、それでも LINQPad の Dump 出力と比較すると見劣りします。

(2) Robert Ivanc のLINQPad Visualizerアドインを使用して、LINQPad のビジュアライゼーションを Visual Studio に取り込みます。それが私のプロディングによるものかどうかはわかりません :-) が、私が記事を書いていたときに存在したいくつかの不都合は、最新のリリースで見事に対処されています。VS2010 を完全にサポートしており、デバッグ時に任意のオブジェクトを調べることができます。

(3) Amazing Pete が以前に説明したように、ブレークポイントを設定できるように、LINQ チェーンの途中に nop ステートメントを埋め込みます。

2016.12.01 更新

そして、上記の記事の続編であるLINQ Debugging and Visualizationというタイトルの記事を書きました。この記事では、OzCode でまもなくリリースされる新機能により、真の LINQ デバッグ機能が Visual Studio 2015 についに登場したことを明らかにしています。この質問に対する@Drorの回答は、そのほんの一部を示していますが、詳細な「方法」については、私の新しい記事を読むことをお勧めします. (そして、私はOzCode で働いていません。:-)

score 7 · Accepted Answer

[免責事項: 私は OzCode で働いています]

LINQ の問題点は、デバッグが難しいことです。単純なクエリを処理する場合でも、開発者は自分のクエリを foreach ループの束にリファクタリングしたり、ログを使用したりする必要があります。LINQ デバッグは、間もなくリリースされるバージョンの OzCode (現在、アーリーアクセスプレビューとして利用可能) でサポートされており、開発者が LINQ コードを掘り下げて、クエリ内でキャッチするのが難しい例外を特定するのに役立ちます。

OzCode でのクエリは次のようになります。

score 6 · Accepted Answer

一時的なブレークポイントを設定せずに LINQ 式の内部に入ることができます。LINQ 式を評価する関数にステップインする必要があります。

var confirm = from l in lines.Lines 
              where (l.LineNumber == startline.LineNumber)
                    || (l.LineNumber == endline.LineNumber) 
              select l;

 confirm.ToArray(); // Press F11 ("Step into") when you reach this statement

 foreach(var o in q) // Press F11 when "in" keyword is highlighted as "next statement"
    // ...

score 3 · Accepted Answer

例外スタックトレースを確認し、実行されたコードの最後のビットを確認します。

score 3 · Accepted Answer

エラーの外観から、line.Lines を見て、その列挙子が適切に実装されていることを確認することをお勧めします。すべきではないときにnullを返していると思います。

ああ、line オブジェクトと line.Lines オブジェクトが null でないこと、または null を返すことも確認してください。

score 0 · Accepted Answer

これはデバッグの方法ではありませんが、次の方法を使用することをお勧めします。

using (var db = new AppContext())
        {
            db.Database.Log = s => System.Diagnostics.Debug.WriteLine(s);
            // Rest of code
        }

その後、デバッグ時に出力ウィンドウをチェックして、LINQ クエリから生成された SQL を確認できます。

linq - LINQ ステートメントをデバッグする方法

9 に答える 9

Related

Reference