Q&A
> VisualStudio2017を2つ開いてC#のライブラリと、そのライブラリを使った実行ファイルの双方のデバッグをしています。
一つのソリューション内に「ライブラリ」のプロジェクトと「実行ファイル」のプロジェクトをつくれば問題は解決するうえに、開発も容易になると思うのですが、そうしない理由があるのでしょうか？
VisualStudio2017を2つ開いてC#のライブラリと、そのライブラリを使った実行ファイルの双方のデバッグをしています。
当初はどちらのVisualStudioでもブレークポイントを設定できていたのですが、いつのまにか、ライブラリのデバッグでブレークポイントの設定が効かなくなってしまいました。
ブレークポイントのマークが白抜き赤枠の○になっており、下記のエラーメッセージが表示されます。
「ブレークポイントは、現在の設定ではヒットしません。このドキュメントのシンボルが読み込まれていません。」
pdbファイルが壊れたのかと思い、双方のVisualStudioでソリューションのクリーン、リビルドをしてみましたが状況は変わりません。
ライブラリのソースに変更を加えた場合は、ライブラリのビルドに加えて、実行ファイルのソリューションでもビルドを実行し、ライブラリ、実行ファイル共に最新の状態になっているはずです。
実行ファイルのソリューションを使ってライブラリの中までたどれるので、ライブラリのデバッグが全くできないわけではないのですが、ライブラリのソリューションからデバッグできないのは不便です。
どのようにすれば元通りになるのか確認すべきポイントなどご助言いただけないでしょうか？よろしくお願いします。
現在の設定
ライブラリのソリューションの設定(異常動作-ブレークポイントがヒットしない)
プロジェクト→(ライブラリ)のプロパティ
開始動作→外部プログラムの開始
→(デバッグビルドされた実行ファイルのフルパス)
実行ファイルのソリューションの設定(正常動作)
プロジェクト→参照の追加→参照
→(デバッグビルドされたライブラリ)にチェック
以上
確かにおっしゃる通りなのですが、同じライブラリを使用するアプリを同時並行で複数開発しているので、便宜上分けています。
最初から動かないのであれば今のやり方がそもそもやってはいけないやり方なのだというのも納得できるのですが、途中から動かなくなったというのが引っかかっています。
とは言うものの、ひとつのソリューションにまとめてみるというご提案も試してみようと思います。
> ライブラリのソースに変更を加えた場合は、ライブラリのビルドに加えて、
・・・と言うことが必要になるのですよね？ であれば、「ライブラリ」の開発は完了してないと理解したのですが？ それなら "一つのソリューション内に「ライブラリ」のプロジェクトと「実行ファイル」のプロジェクト" とするべきと思ったのです。 そうすれば、
> ライブラリのソースに変更を加えた場合は、ライブラリのビルドに加えて、実行ファイルのソリューションでもビルドを実行し、ライブラリ、実行ファイル共に最新の状態になっているはずです。
・・・と言うのは Visual Studio 任せで済むはずですから。
おっしゃっていることは理解できます。試しにライブラリのソリューションに実行ファイルのプロジェクトを既存のプロジェクトとして追加してみましたが、結果は同じでした。それどころか個々のプロジェクトのビルドは問題なくできるものの、ソリューションをビルドすると名前空間が見つからないとか謎のエラーが出てきたので、次は、新規プロジェクトで追加してみます。ソースをコピーして設定をやり直したら正常に動く可能性が高いでしょうから。
> 結果は同じでした。
それは単に設定に問題とか、何か見当違いのことをされているのが原因ではないかと思います。
だと思います。なにが見当違いなのかを知りたくて質問していますので。新規プロジェクトで追加したら動作しました。原因がわからないまま解決したということになりそうです。
> 新規プロジェクトで追加してみます。
ご存じかもしれませんが、ポイントを回答欄に書いておきます。質問に対する直接の回答ではないですが、画像はここには貼れませんのでご容赦を。
質問者さん、無言になってしまいましたが、結局どうすることにしたのか書いてください。考え中なのかもしれませんが、第三者にとっては放置しているように見えます。結論が出ていたらそれを書いてクローズしてください。
失礼しました。この質問はクローズさせていただきます。
回答4件
0
自己解決
原因についてはなにも解決していないのですが、デバッグはできる状況になっているので解決済みとします。
ブレークポイントがヒットしない状況があったのは確かなのですが、現状は、デバッグ開始直後にブレークポイントがヒットしない表示(白抜き赤枠の○)になるものの、ボタンを押して処理を開始すると、ブレークポイントが赤丸になってヒットする表示になり、ブレークポイントの該当箇所できちんと停止するようになっています。
開始直後に白抜き赤枠表示になるのは、アプリの処理をTask.Run()で別スレッドとして開始するためなのかもしれませんが、推測の域を出ていません。
ブレークポイントがヒットする場合にも開始直後に白抜き赤枠に変わってしまう状況で条件を切り分けようとしていたので、ブレークポイントがヒットするケースとヒットしないケースを正しく切り分けできていないということになります。
本来であれば調査をやり直すべきですが、現時点でブレークポイントが使えており、実質困っていないので、
この質問は閉じさせていただきます。
投稿2020/09/18 06:18
総合スコア6
0
新規プロジェクトで追加してみます。
ご存じかもしれませんが、ポイントを以下に書いておきます。質問に対する直接の回答ではないですが、画像は質問へのコメント欄には貼れませんのでご容赦を。
同一ソリューションの中にライブラリ LibraryA と、それを利用するアプリ Mvc5App の 2 つのプロジェクトを配置。Mvc5App の参照設定に LibraryA を加えると、LibraryA と Mvc5App の依存関係が自動的に生じます。
上の画像のように、Mvc5App を右クリックして出てくるコンテキストメニューから「ビルドの依存関係(B)」でそれを見ることができます。
プロジェクトの依存関係
プロジェクトのビルド順序
あとは Visual Studio にお任せで済むと思います。
投稿2020/09/14 06:38
退会済みユーザー
総合スコア0
0
このへんは確認されたでしょうか。
Visual Studio デバッガーでのブレークポイントのトラブルシューティング
あと、ビルド時に出力されたファイル等を一度全て削除して、リビルド後に実行してみるとどうでしょう。
投稿2020/09/14 04:09
退会済みユーザー
総合スコア0
あなたの回答
tips
プレビュー
