2

私はここでこの質問をし始め、非常に有益な答えを得ましたが、それでも問題を回避することはできません。既知の問題であるため、この質問は終了しました。私はそれが既知の問題であることを知っています：私の質問はそれについて私がおそらく何ができるかということです。

要約すると：

  1. VSデバッガーは、Windows 64ビットシステム（私の場合はWin 7 64ビット）でデバッグするときに、Form_Loadイベント（またはそれからの呼び出し）で発生する未処理の例外を飲み込みます。現状では、これによりVSは開発環境として役に立たなくなります
  2. 1つの提案は、コードをFOrm_Loadイベントではなくコンストラクターに移動することでした。コードが見えなくなって「設計者が作成した」モジュールに移動するため、これは実行したくありません。それらのモジュールは、私がまだ変更する能力がないコードでいっぱいです。そして、私はデザイナーが私がそこに置いたコードを一掃したり変更したりしないとは信じていません。
  3. もう1つの提案は、初期プロシージャ（Sub Mainなど）にコードを挿入することにより、未処理の例外をダミーの空の例外ハンドラーにポイントすることでした。 これは動作します。ここでの問題は、アプリケーションフレームワークをオフにした場合にのみ、起動時にサブメインを実行できることです。次に、「メインフォームまたは最後のフォームが閉じるまで」の有効期間でアプリケーションを実行できません。
  4. スタートアップフォームのサブメインが実行され、適切なタイミングで（つまり、Form_Loadの前に）実行されていると思いました。したがって、引き続きApplication Frameworkを使用して、この特別なコードを何よりも先に実行することができます。私はここで間違っているかもしれません。いずれにせよ、私はそのフォームのコードを少し変更しましたが、Mainは時間内に実行されなくなりました-実行された場合（Form_Loadが最初に実行され、同じ問題が発生します）。コードをForm_Loadに移動しようとしましたが、それ自体でエラーが発生します。
  5. 想定される修正プログラムがあります（KB976038）。私はそれを適用しました（再起動が必要です）：しかし、例外が飲み込まれる代わりに、vshost.exeアプリケーションエラーが発生し、それでもコードをデバッグできません。苛立たしいことに、アプリケーションエラーをOKすると、VSデバッガーに通常の未処理の例外ボックスが表示されますが、約1/10秒で消えます。

だから私のオプションは何ですか？

ここでの共通のスレッドは、私は経験豊富なプログラマーですが、VB.NETとVB6で物事を成し遂げることに慣れており、この問題の原因の完全な説明を理解する能力があるということです。

考えられるすべての対策は本当に私の能力を超えており、私が気づいてさえいないかもしれないあまりにも多くの落とし穴を紹介します。私は考えずにはいられません-なぜ私はコーディングに取り掛かることができず、例外を破るために信頼できるデバッガーを使用して、私が犯す避けられないコーディングの間違いに対処できないのですか？

現時点では、（私よりも専門家からのアドバイスを受けて）VSに未処理の例外を適切にキャッチして中断させると、これは今日だけになると思います。明日または来週のコードで私が行うことが、VSを今のところ適切に動作させている慎重に構築されたセーフティネットを壊さないかもしれないかどうか誰が知っていますか？

私の.NETの専門知識では、この段階でコンストラクター/デザイナーが作成したコードの近くに立ち入ることは許可されるべきではないことを自由に認めます。私はただ物事を成し遂げたいのです！したがって、私のオプションは次のようになります。

  • 私がこの問題の解決策を決して壊さないように、すべての筋金入りのことを学びましょう。これには、数年ではないにしても数か月かかります。また
  • 諦めて、XPのVS2008Expressに戻ります。また
  • 会社にWindows764をビンに入れるように説得し、開発OSとしてWindows732を提供します。

どんなアイデアや提案も歓迎します！

編集： 以下の@roadwarriorによって提案されているように、元の質問への回答で提案された回避策と、私がそれらで見つけたものは次のとおりです。

1プロジェクト+プロパティ、[ビルド]タブ、プラットフォームターゲットをAnyCPUに変更

すでにそのように設定されており、変更することはできません。TargetCPUを「AnyCPU」からx86または64ビットに変更しようとしました-効果はありません。

2デバッグ+例外、CLR例外の[スロー]ボックスにチェックマークを付けます

意図的に例外を処理し始めるとすぐに、実行/テストを悪夢にします（これは私がよく行うことです）。すべての例外は、処理されるかどうかに関係なく、「停止」になります。

3Loadイベントハンドラーにtry/catchを書き込みます

これもあまり面白くありません。開発のこの段階で、問題の原因となっている線を確認したいと思います。On Error Gotoのスコープ内にあったVB6のデバッグコードを常に嫌悪し、誰かがコールスタックの6ステップ上の手順を実行しました。私は自分のプロジェクトでそのように始めたくありません！

4 Main（）メソッドでApplication.SetUnhandledExceptionMode（UnhandledExceptionMode.CatchException）を使用して、メッセージループの例外トラップがデバッグモードで無効にならないようにします。ただし、この設定では、未処理のすべての例外のデバッグが困難になり、ThreadExceptionイベントはほとんど役に立ちません。

最後の文のコメントがわかりません。しかし、このようなものはうまくいきました。私が以前の質問に答えてNeoliskによって提案されたように、私がしたことは、サブメインでこれでした：

Public Sub Main()
    AddHandler Application.ThreadException, AddressOf ThreadExceptionHandler
    Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException)
    AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf UnhandledExceptionHandler

    Form1.Show()
End Sub

Friend Sub ThreadExceptionHandler(sender As Object, e As System.Threading.ThreadExceptionEventArgs)

End Sub

Friend Sub UnhandledExceptionhandler(sender As Object, E As System.UnhandledExceptionEventArgs)
End Sub

これは私のバージョンのneoliskのコードでした-私のバージョンのVS/.NET（2012、4.5）のように、2つのハンドラーが異なる署名を持つ必要があるようにコードを変更する必要がありました。これに関する2つの問題：

a）「アプリケーションフレームワークを有効にする」のチェックを外さないと、起動時にサブメインを実行できません。これを行うと、Form1.Showにフォームが表示され、サブメインの最後に到達します。アプリケーションが閉じると、フォームはすぐに消えます。アプリケーションの[設定]ウィンドウの[シャットダウンモード]設定を覆しましたが、元に戻す方法がわかりません。

b）このコードは機能しますが、なぜ、どのように、すべての例外をカバーするのか、[デバッグ/例外]ダイアログでチェック/チェック解除することを決定するものとどのように関連するのか、またはその他の落とし穴の副作用があるのか​​、私にはほとんどわかりません。デバッグ時または実行時。

5コードが実際にLoadイベントハンドラーに属しているかどうかを検討します。それが必要になることは非常にまれですが、ロードが重要だったVB6プログラマーに人気があります。ユーザー設定と自動スケーリングが適用された後、実際のウィンドウサイズに関心がある場合にのみ、ロードが必要になります。他のすべてはコンストラクターに属します。

けっこうだ。元VB6プログラマーとして、私はForm_Loadの使用に慣れていますが、進歩して新しいことを学び、コードをフォームのNew（）コンストラクターに移動しましょう（実際に_Loadイベントに含まれる必要のあるコードがないことを願っています） 。これで、実行が問題の行に到達したときに少なくとも例外ダイアログが表示されます。ただし、新しいウィンドウの上部に「使用可能なソースがありません（crlf）呼び出しスタックに外部コードのみが含まれています」と表示されます。この特定のケースでは、コードの間違いは私がここで見たものからデバッグ可能です（それは愚かなタイプミスです）-しかし、物事がより複雑になったときにこのようにデバッグすることは悪夢になります：何かの状態が何であるかを見る機会はありません。

一般的なコメント：

1.このプロジェクトを私たちが持っている1台のWin732ビットマシン（私のマシンではない）で実行しましたが、何の問題もありませんでした。これが私の推奨する解決策です。開発にWin764ビットを使用するのをやめるだけです。

2.「デバッガーを持っているのはラッキーだ」というコメントは面白いですが、役に立ちません。これはVS2012であり、これはおそらく動作するデバッガーを備えた開発環境であり、£££を支払う必要があります。私は自分が何をしているのかをいつ知っているかを知るのに十分長い間プログラムしてきました、そして私が何かをいじっているとき、私はそれを理解していないのでそうすべきではありません。私が特に理解していないのは、基礎となる構造ではなく（ZX81マシンコードで歯を食いしばって、そこに戻りたくない...）、VS自体です。必要に応じて、たとえばVSで例外ハンドラーを変更する方法について詳しく知ることができてうれしいですが、無意識のうちにそこに飛び込みたくないのは間違いありません。

4

2 に答える 2

2

これは既知の問題であるためではなく、重複として質問を閉じました。元の質問には、考えられる回避策について説明しているHansPassantによる良い回答があります。

さまざまな回避策のどの部分が「ハードコア」であるかをお知らせください。簡単な説明を提供します。ボンネットの下で何が起こっているのかについての理解が深まるので、これをさらに調査することは実際にあなたにとって良いことだと思います。

于 2012-11-16T16:07:06.053 に答える
1

あなたの懸念＃3に関して：ShowDialog()の代わりに使用してみてくださいShow()、それはこの（メイン）フォームが閉じられるまでアプリケーションを実行させます。このように本番アプリケーションを実行しています。メインフォームがない場合は、デザインを再検討することをお勧めします。

x64から離れる前に、2008 R2以降、32ビットバージョンのOSがないことを考慮してください。つまり、ソフトウェアをアプリケーションサーバーで実行する場合、それはx64になるため、それに適応する必要があります。

于 2012-11-16T19:45:11.013 に答える