現在、ユーザーがアプリケーションを終了したい場合、必要ないくつかのこと (サーバーからの切断、ユーザー データの保存など) を行ってから、次のことを行います。
これは終了するのに数秒かかり、実際の目的には役立ちません (すべてがサーバーに既に保存されているため、そこで何が起こるかはあまり気にしません)。
代わりにこれを使用すると、考えられる欠点なしで即座に終了しました。
System.Diagnostics.Process.GetCurrentProcess().Kill();
プロセスを終了して、CLR に AppDomain を削除させないのはなぜですか?
共有リソース (IO ファイル ハンドラーなど) を慎重に破棄することが重要であることはわかっています (だから、それに答えないでください:))。
プロセスを強制終了すると、finally ブロックが実行されず、実際にはクリティカルである可能性があるクリティカル ファイナライザー オブジェクトも実行されず、システム レベルでリソース リークが発生する可能性があります。また、将来、他の誰かがコードを保守しているときに予期しないバグが発生する可能性もあります。なぜなら、彼ら (またはあなた) は頭をひねらなければならず、finally ブロックを書くたびにそれが実行されるかどうかを考えなければならないからです。
Process.Kill()まず、あなたはではなくを意味していると思いますProcess.TerminateProcess()。第二に、プロセスを強制終了すると、プロセスが取り除かれます。クリーンアップ コードは実行されず、アプリケーションはキルをキャンセルできません (たとえば、ユーザーが保存していないデータを持っている場合)。あなたがそれに満足しているなら、それを求めてください。
それは確かに良い質問です！
むかしむかし (10 年以上前)、私は VB6 アプリを作成しました。これは、WinINet OCX (またはそれが呼ばれるもの) で確認されたバグが原因で、それが話している Web サーバーで使用されている特定の証明書が原因で、終了時にハングしました。
このバグを回避する方法がなく、私は TerminateProcess を使用しました。私が知る限り、このアプリは数年間、数千台のマシンで使用されていましたが、このハッキングに関する問題は聞いたことがありません!
エラーやリークをキャッチする方法がないサードパーティのライブラリを使用すると、クラッシュ MessageBox をスローせずに終了する唯一の方法は、プロセスを強制終了することです。
ファイル/ネットワーク ストリームに書き込んでいる場合、書き込みが不完全になる可能性があることに注意してください。
アプリケーションが破損したデータをそのように処理する準備ができている場合、それを行わない理由はありません。ただし、他の方法で終了できる場合は、それをお勧めします。
ファイナライザーは実際には実行されない可能性があるため、プロセスを強制終了することは、遅いファイナライザーや例外をスローするファイナライザーなど、ファイナライズ コードをスキップする他の理由と大差ありません。
全体として、特にすべてのウィンドウがすぐに非表示になり、ユーザーに対して「消える」場合は、アプリケーションを閉じるのに数秒かかることについてあまり心配しません。ただし、閉じるのに数十秒かかる場合や、ユーザーがアプリケーションを再度実行する可能性が高く、複数のインスタンスをサポートしていない場合は、呼び出すProcess.Killことをお勧めします。
終了するのに時間がかかるアプリケーションをいくつか知っていますが、いつの日か、ユーザーである私にそうさせるのではなく、残忍に自分自身を殺しているのを見たいと思っています (OS の再起動は特に面倒です)。
System.Environment.Exit（int）を使用してみませんか？コードを保存するためだけにこれを実行したいようです。私にとっては、Exitの呼び出しが実行され、シャットダウンがより制御され、ファイナライザーとクリティカルファイナライザーが実行されることを確認する方がはるかに明確です。