次のようなクラスがあります。
_public class MyService
{
private MyService(){}
public static string GetStuff()
{
var stuffDid = new MyService();
return stuffDid.DoStuff();
}
private string DoStuff()
{
//do stuff
}
//other private helpers
}
_
明らかに多くのことを省きましたが、それは一般的なシェルです。
今、私はユニットテストを持っています:
_[Test]
public void MyTest()
{
var results = MyService.GetStuff();
}
_
単体テストにブレークポイントを設定すると、results
にデータがあることがわかります。ただし、MyService
全体に文字通りブレークポイントを設定し、中かっこで区切らない限り何もヒットしません。 results
にデータがあるため、理解できないのですが、return
内のMyService
ステートメントがヒットするはずです。
何か不足していますか?何かの最も基本的なルールを完全に忘れましたか? MyService
で何もヒットしないのはなぜですか?そして、_F11
_を使用して手動でステップインした場合、それはただホップし、期待どおりにすべての行を通過しません。また、手動でステップスルーするとき、元々ヒットするはずだった特定のコードをヒットする傾向があります。また、switch
ステートメントは、最初のオプションが何であれ、デフォルト値のように見えます。切り替えられる値も、異なるcase
を明確に入力する必要があります。
MyService
コンストラクターpublic
を作成し、static
メソッドをすべて削除しようとしても、まだ機能しません。
編集:私のテストと「コア」コードは同じソリューションにありますが、異なるプロジェクト(それぞれTest
とCore
)です。他のテストでは、Core
のブレークポイントにヒットする問題はありません。これは特定のテスト(MyService
をテストしている唯一のテスト)でのみです。
編集2:
PDBファイルを削除し、ソリューションをクリーンアップしました。まだ何もありません。
これは、コードカバレッジがオンになっていることが原因でした。
これをオフにすると問題が修正されました。
コードカバレッジを無効にする方法については、以下のリンクをご覧ください。
いくつかのアイデア。
Debugger.Break()
を挿入してみてくださいコンピューターの日付を調整しましたか?これは実際にビルドプロセスを台無しにする可能性があります。その場合、すべてのobj/binフォルダーを手動で削除し、再コンパイルします。
Test
とCore
の両方ではなく、1つのプロジェクトのみをデバッグしているためです。
一度に複数のプロジェクトをデバッグするようにVSを設定できます。これはright-click your solution > Properties > Common Properties > StartUp Project
ここでは、「複数のスタートアッププロジェクト」を設定できます
Core
とTest
の両方を開始するように設定するだけです。これで問題が解決する場合があります。
「ブレークポイントがヒットしない」という明らかな問題を引き起こした非常に具体的なシナリオがあります。
ここで他の答えはそれについて言及していなかったので、同じ問題を抱えている人を助ける機会に私のものを追加します。
私の場合、解決策はばかげていたので、使用するLINQの数が多ければ、もっと早くこれを理解するはずでした。 IEnumerableを返すメソッドを実行する場合、その中に含まれるreturnステートメントは実際には_yield return
_ステートメントであり、そのメソッドを呼び出しても実行されません。
ToList()
やCount()
など、IEnumerableオブジェクトから別のメソッドを呼び出すと、実際に実行されます。 thenのみがメソッドが実行され、ブレークポイントに到達します。
デバッガシンボルを使用してアセンブリをビルドしたことを確認してください。
このオプションには「フル」を入力する必要があります。
ブレークポイントがヒットしないコードファイルを含むプロジェクトを右クリックします。 「プロパティ」を選択します。
プロジェクトプロパティを開いたら、[ビルド]タブを選択します。タブページの下部にある「詳細...」ボタンに注意してください。 (「出力」グループ内)
このボタンをクリックして、「デバッグ情報」プロパティに「フル」を選択します。これは、ブレークポイントがヒットしない理由です。 Visual Studioは、pdbファイルに保存されているシンボルを使用して、ブレークポイントの正確な位置を見つけます。これらのファイルが作成されない場合、ブレークポイントはヒットしません。プロジェクトファイルの構造を整理するために、これらのファイルの作成を無効にした可能性があります。これは、これらのファイルが必要だと認識した状況でした。
私は最近同じ問題を抱えており、頭を壁にぶつけていました。
答えはかなりばかげていることがわかりました。どういうわけか、私のテストプロジェクトはメインライブラリプロジェクトと同期しなくなりました。テストとライブラリのデバッグバージョンを作成していましたが、テストプロジェクトはbin/Release
フォルダ。プロジェクト参照を再作成しただけで、すべてが修正されました。
追伸デバッガーはライブラリー関数の内部に入りましたが、途中で1行スキップしました。
これは、テストサンドボックスでpdbファイルが更新されていないようです。
1)デバッグモードになっていることを確認します。
2)pdbファイルの展開項目を明示的に含めることはできますか?
3)1と2が失敗した場合、ビジュアルスタジオで再起動が必要になることがあります:)
DoStuffを静的にする必要があります。
private static string DoStuff()
{
//do stuff
}
これは25のプロジェクトのうち1つで発生し、すべて同じソリューションでした。他のプロジェクトはブレークポイントを尊重しましたが、この1はそうではありませんでした。ソリューションからプロジェクトを削除(アンロードせずに削除)すると、プロジェクトへのすべての参照が破損し、ソリューションに再び追加されました。
それでもうまくいかない場合は、問題のあるプロジェクトを最初から作成し直して、その新しいプロジェクトをソリューションに追加します。
これが純粋な幸運とは別に働いた理由について私が持っている最良の説明は、VSのあるバージョンから別のバージョンにプロジェクトを何年も何度も移行し、おそらくそれらの移行の1つがこの問題を引き起こしたということです。
ソリューションをクリーンアップして再構築し、スタートアッププロジェクトも実行します。
構成プロパティが設定されているかどうかを確認するために、[ビルド]> [構成マネージャー]をご覧ください。開発中の場合は、[プロジェクトのプロパティ]を調整する必要があります-> [詳細設定]をクリック-> [出力タブ]でデバッグ情報を「フル」に変更します。
また、開発モードではない場合でも、ステップ2に従うことができます
コードは「サービス」を示しており、別のプロセスとして実行されている可能性があります。その場合は、アセンブリをロードできるため、ブレークポイントは赤い丸で囲まれますが、別のプロセスで実行されているアセンブリの別のコピーが実際に要求を処理します。
経験から、Visual Studioにはサービス、特にWindowsサービスをデバッグする明確な方法がないことがわかっています。 GetStuffにコードを追加してテキストファイルに印刷してみてください。これにより、少なくともコードがヒットしていることがわかります。サービスを作成するとき、私はしばしばテストのためにこの方法に頼ります。
これはかなりあいまいです:
ハードドライブ上の同じ物理的な場所を指す異なるアプリケーションプールを持つ2つの仮想ディレクトリがないことを確認してください。開発中、これはテストのために、または誤って発生することがあります。
私は技術について100%明確ではありませんが、2つのAppPoolと2つの仮想ディレクトリがあり、物理パスはIIS/Visual Studioで実際に他のアプリケーションプールではなく他のアプリケーションプールにマップされていると推測されるため、ブレークポイントにヒットしませんでした実行中。
VSは、デバッグ時に使用されるコードとは多少異なるソースコードを使用して生成された.pdbファイルを使用する場合、説明したとおりに動作します(ブレークポイントにヒットせず、ステップスルー時にヒットするはずのないコードにヒットします) 。これがあなたのケースであることを保証することはできませんが、同じファイル名を持つ古い/異なるコードに対して生成されたビルド済みライブラリとして提供されたコードにステップインする必要があるとき、そのような動作を何度も観察しました/シンボル。
GetStuff
メソッドにThread.Sleep(5000)
を追加し、Attach to Processを使用してみてください。
Visual Studio>ツール>プロセスにアタッチで、その行の下のブレークポイントがヒットするかどうかを確認します。
おそらく、あなたのTest
プロジェクトは、Core
(ソースコード)プロジェクトではなく、古いCore
バイナリを参照していますか?
テストプロジェクトに参照を追加し直してください。
Test
プロジェクトに移動し、Core
プロジェクトへの参照を削除します。
[参照]フォルダを選択して右クリックし、メニューオプションを選択して新しい参照を追加します。 [参照マネージャー]ダイアログで、左側の[Solution
を選択してからProjects
を選択していることを確認します。次に、Reference Managerダイアログの中央で、Core
プロジェクトを選択(チェック)します。
デバッグを再試行し、それが役立つかどうかを確認してください。
私は同様の問題に遭遇しました。私にとっては、*.testrunconfig
ファイルを使用したVS2010からVS2012への移行が悪いことがわかりました。古いものを削除し、新しいものを設定して問題を解決しました。
最初にプロジェクトを右クリックしてプロジェクトを再構築してみてください>プロジェクトを再構築する
それがうまくいかなかった場合、これを確認してください:
Right mouse click your project
select [Properties]
select the [Build] tab
make sure [Define DEBUG constant] and [Define TRACE constant] are checked
Click the [Advanced] button at the bottom of the Build tabpage
Make sure that [Debug Info:] is set to [full]
Click [OK] and rebuild the project ;-)
それがあなたのために働くことを願っています! (ステップ6は.pdbファイルを生成します。これらはデバッグシンボルです)
段階的にデバッグするには、2つのことを行う必要があります。最初にブレークポイントを設定し、次にコードを実行しているプロセスにデバッガーを接続する必要があります。 IIS Expressで64ビットマシンを使用している場合、コードを実行しているiisexpress.exeをアタッチする必要があります。CTRL+ ALT + P、プロセスへのアタッチウィンドウに到達しますアタッチ後、コードが一致した場合にブレークポイントにヒットする必要があります。
いくつか試してみるもの:
ロードされたシンボルがデバッグされた実行可能ファイルと一致するかどうかを確認します。
VSコマンドプロンプトを開き、デバッグする実行可能ファイルが存在するディレクトリに移動します。次に、dumpbin /PDBPATH:VERBOSE MyServiceExecutable.exe
そして「PDB年齢の不一致」の出力をスキャンします(参照: http://msdn.Microsoft.com/en-us/library/44wx0fef.aspx )
VS 2012についてはわかりませんが、VSの古いバージョンには、異なるフォルダーにある場合でも同じ名前の2つのソースファイルがプロジェクトにある場合、間違ったソースファイルが表示されるというバグがありました。そのため、プロジェクトに同じ名前の別のソースファイルが含まれている場合は、それらのいずれかの名前を変更すると役立つかどうかを確認してください。 (更新:VS 2012のようです 影響も受けます 。)
単体テストでは、ブレークポイントにヒットしていなかったため、テストをデバッグするのではなく、テストを実行していることに気付きました。テストエクスプローラーの上部には、「すべて実行」、「失敗」、「合格」などのオプションがあります。テストを実行すると、ブレークポイントはヒットしません。テストをデバッグするには、テストエクスプローラーでテストまたはテストのグループを右クリックし、[選択したテストのデバッグ]を選択します。
リリースモードの場合は、デバッグモードに切り替えます。
愚かなことに、テストプロジェクトがビルドされるように設定されていませんでした。
同じ問題があります。たぶん私の解決策があなたの問題を解決するのに役立つでしょう。 [プロセスにアタッチ]オプションで[アタッチ]オプションの値[Avtomatic:Native code]を選択します。宜しくお願いします。