エラー：ファイルbin / Debug /…にアクセスできません。別のプロセスによって使用されているためです

プロジェクトをデバッグすると、次のエラーが発生します。

"ファイル" obj \ Debug \ My Dream.exe "を" bin \ Debug \ My Dream.exe "にコピーできません。プロセスはファイル 'bin \ Debug \ My Dream.exe'にアクセスできません処理する。"

プロセスエクスプローラーを使用して、MyApplication.exeが出ていたのを確認しましたが、以前デバッグを停止しましたが、システムプロセスは引き続きそれを使用しています。コードを変更してデバッグを開始するたびに、それが起こります。プロジェクトをUSBにコピーしてデバッグすると、問題なく実行されます。

どうして？このエラーを修正するにはどうすればよいですか？

私はWindow 7 Professionalを使用しています。Xpでは、このエラーは発生していません。

ええと、これは古い問題で、Visual Studioで時々表示される問題です。それは私に数回噛まれて、何時間も再起動してVSと戦っていました。ここで何度も議論されていると思います。MSDNフォーラムでも話題になっています。実際の解決策はありませんが、いくつかの回避策があります。ここで調査を開始します。

VSがファイルのロックを取得してから解放していないことが原因です。皮肉なことに、このロックはVS自体がファイルを削除するのを防ぎ、アプリケーションを再構築するときにファイルを再作成できるようにします。唯一の明らかな解決策は、VSを閉じて再起動し、ファイルのロックを解除することです。

私の元の回避策は、bin / Debugフォルダーを開き、実行可能ファイルの名前を変更することでした。ロックされている場合は削除できませんが、名前は変更できます。したがって、末尾などに数字を追加するだけで、すべてのウィンドウを閉じてVSが再起動するのを待たずに作業を続けることができます。一部の人々は、古い出力ファイル名の最後にランダムな文字列を追加するために事前構築イベントを使用してこれを自動化しました。はい、これは巨大なハックですが、この問題は非常にイライラさせ、衰弱させ、あなたは何でもします。

私は後で、もう少し実験した結果、デザイナーの1人が開いている状態でプロジェクトをビルドしたときにのみ問題が発生するように見えることを学びました。したがって、長期にわたって機能し、愚かなエラーの1つに対処することができなくなった解決策は、WinFormsプロジェクトをビルドする前に、必ずすべてのデザイナーウィンドウを閉じることです。はい、これも多少不便ですが、1時間に2回以上VSを再起動する必要があるため、間違いなくズボンを破ります。

これはWPFにも当てはまると思いますが、私はWPFを使用しておらず、そこで個人的に問題を経験したことはありません。

VS 2012 RCでの再現もまだ試していません。それがまだ修正されているかどうかはわかりません。しかし、これまでの私の経験では、Microsoftが修正したと主張した後でも、なんとかポップアップし続けています。VS 2010 SP1にはまだ存在します。もちろん、彼らのプログラマーが何をしているのか知らないバカだと言っているのではありません。バグの原因は複数あるか、実験室で確実に再現するのが非常に難しいことがわかります。それは私が個人的にバグ報告を提出していないのと同じ理由です（私は他の人を+1しましたが）。

_{<特に誰にも向けられていない暴言>}

このエラーはVisual Studio 2008でも発生しました。VisualStudio 2012で再び発生し、蔓延しました。

これが私がすることです。

これを問題のあるプロジェクトの事前ビルドイベントに貼り付けます。

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

コンピューター（右クリック）->管理->サービスとアプリケーション->サービス->アプリケーションエクスペリエンスの有効化

私のために働いた！

Visual Studio 2013でも同じ問題が発生しました。プロジェクトでこれが発生した原因はわかりませんが、ソリューションをクリーニングして再構築することで修正できました。

1. ビルド>クリーンソリューション
2. ビルド>ソリューションの再構築

少なくとも私の場合、ビジュアルスタジオ2012が少なくとも2つのmsbuild.exeゴーストプロセスを作成していることに気付きました。これらのゾンビがファイルロックを表示しているようです。

msbuild.exeの強制終了は1回限りの解決策であり、ビルドごとに実行する必要があります。

しかし、私は並列ビルドを一度に無効にできることを理解しました-[ツール]> [オプション]> [プロジェクトとソリューション]> [ビルドと実行]> [並列プロジェクトビルドの最大数]に進みました-デフォルトでは、値は8です。 1に切り替えました。チャームのように機能します。

もちろん、ビルドは少し遅くなりますが、残念ながら安全です。少なくともこの特定の小さなプロジェクトでは、1つ以上のビルドスレッドは必要ありませんでした。

これは古い質問であることを理解しています。残念ながら、の.net core 2.0アプリケーションで同じ問題に直面していましたvisual studio 2017。それで、私に役立つ解決策を共有することを考えました。このソリューションの前に、以下の手順を試しました。

1. ビジュアルスタジオを再開
2. すべてのアプリケーションを閉じました
3. ソリューションをクリーンアップして再構築

上記のいずれの手順でも問題は解決しませんでした。

次にTask Manager、選択したdotnetプロセスを開き、[タスクの終了]ボタンをクリックしました。後でVisual Studioを開いたところ、すべてが正常に機能していました。

単体テストの実行中にこの問題が発生した場合は、ここで私の回答を参照してください。回答は以下にコピーされました：

セバスチャンの答えに基づいて、私はテストプロジェクトにビルド前のステップを追加して、vstest.*実行中の実行可能ファイルを自動的に強制終了しました。次の事前構築コマンドが私にとってうまくいきました：

taskkill /f /im vstest.*
exit 0

このexit 0コマンドは、vstest.*実行可能ファイルが実行されていないときにビルドの失敗を防ぐために最後にあります。

最近、私はVisual Studio 2012で同じエラーの説明で問題を抱えています。「別のプロセスで使用されているため、プロセスはファイルにアクセスできません...」

まずこれを修正するには、それをまだ使用しているアプリケーションを理解する必要があります。「MSBuild」や「MSBuildホスト」などのすべてのプロセスをシャットダウンしました。しかし、これでは十分ではありません。「コードコントラクト」をインストールして有効にすると、DLLでこの操作をチェックしてハングアップすることがあります。

したがって、「CCCheck.exe」のすべてのプロセスを停止する必要があり、それだけです。

最後に、プロセスがDLLを使用していることを理解するために、ファイルマネージャーで「obj」フォルダーを削除しようとすると常にこの操作が失敗し、ハングした操作の説明が「メッセージウィンドウ」に表示されることがあります。また、亜種として、「Sys Internals Suite」アプリケーションを使用してみることができます。

私のために働いた。タスクマネージャ->プロジェクトの名前->タスクの終了。（私は私のプロジェクト名で3つの同じプロセスがありました）;

VS 2013; 勝利8;

アプリケーションの以前の実行（たとえば、デバッグオプションなしで開始）が実際に停止していることを確認します。私はWPFアプリケーションで作業していて、デバッグなしで開始し、エラーが発生し続けると最小化されました。アプリケーションを閉じた後、VSの動作は通常に戻りました。

Visual Studio 2017でこの問題に悩まされています。約2〜3週間前に開始され、私の生産性に大きな影響を与えています。CleanとRebulidは機能していません。マシンを再起動してもうまくいきません。

この問題に対処する1つの方法は、問題のあるアセンブリをクリーンアップし、すぐに実行するプロジェクトを（再ビルドではなく）ビルドすることです。これは約30％の時間で機能します。

ただし、おそらく私が見つけた最も信頼できる解決策は、開発者コマンドプロンプトを開いてmsbuild直接使用することです。私は過去3日間これを行ってきましたが、これまでのところ問題は一度も発生していません。

私の場合は、「すべてのファイルを表示」を有効にしました。Visual Studio 2017

を実行しますtaskmanager。
それを見つけnetcoreて削除します。
その後、手動で、またはを実行してファイルを削除できますClean。

これは純粋な推測であり、答えではありません。

しかし、私はしばらくの間この問題を抱えています。

しばらくして、VSとAVの予防策の相互作用を疑うために来ました。

いくつかの演奏の後、それはと思われるかもしれ私は下のようにすべての私のように、アンチウイルスを修正するとき離れてしまいました

C：\ Users [ユーザー名] \ AppData \ Local \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

フォルダはリアルタイム保護に含まれていませんでした。

最初にビルドが実際にDLLを書き込んだように見え、次にそれを最終的なビルド場所にコピーします。

手遅れかもしれません。しかし、私は同様の問題に遭遇し、私の場合、プロジェクトには自己参照がありました。したがって、参照から削除することは魅力のように機能しました!!!

フォームを閉じたりVisualStudioを再起動したりせずに最も簡単な方法は、プロジェクトのコンパイルページに移動して[詳細なコンパイルオプション...]ボタンをクリックすることです。次に、いずれかのオプションに変更を加え（たとえば、[デバッグ情報の生成]を[完全]から[pdbのみ]に変更）、[OK]をクリックします。それは毎回機能し、MSがこのバグを修正するまで実行する必要があります（VS2012からVS2013に切り替えるまで、私はこの問題に遭遇したことがありません）

別の注意点として、プロジェクトまたはソリューションをクリーンアップできない場合、ビルドできません。ファイルは必ずVSによってロックされています（ウイルス対策の問題ではなく、少なくとも私の場合はそうではありません）。

私はこれらすべての提案と他の場所で見つかった他の提案を試しましたが、私のために働いた唯一のことは自分のコンピューターを再起動することでした。その後、私はクリーンなソリューションを実行した後、再構築しました。参考のためにVisual Studio 2013を使用しています。

私はこれと同じ問題に遭遇しましたが、私が見つけたのは、複数のWindowsフォームアプリケーションがバックグラウンドで実際に実行されていることです。これは、アプリケーションに2つのフォームがあり、メインフォームではない2番目のフォームを閉じたためにアプリケーションが完全に終了しない場合に発生します。

通常、アプリケーションを実行します

• そのexeを介してまたは
• デバッグなしで実行

解決策は、Windowsフォームアプリケーションの他のインスタンスを閉じることです。これは、常にアプリケーションインスタンスを閉じる方法の1つです。

事前構築コマンド

(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)

助けた

[解決済み]エラー：別のプロセスで使用されているため、ファイルbin / Debug /…にアクセスできません：

最初にフォームをロードしてから、時々自動的に消えて2番目のフォームが画面にロードされるなど、2つのウィンドウフォームを次々に実行しようとしたときにこのエラーが発生することをお知らせします。

基本的には、バックグラウンドで実行されている最初のフォームと、このエラーの主な理由を閉じる必要があります。

最初のフォームを閉じるには、2番目のフォームロードイベントハンドラーにこれらの2行のコードを追加する必要があります。

    Form1 form = new Form1();
    form.Close();

これはエラーを完全に解決します。

1つの簡単な解決策は、bin \ Debugフォルダーに移動し、そのフォルダー内のすべてのファイルを削除してから、再ビルドすることです。機能しない場合は、Visual Studioを閉じてから、ファイルエクスプローラーを使用してbin \ Debugフォルダーに移動し、左側のコーナーで、[ファイル]> [コマンドプロンプトを開く]> [管理者としてコマンドプロンプトを開く]をクリックし、次のコマンドを入力します "DEL / F / Q / * ">次に再構築

私はCody Greyの回答が部分的に役に立ったと感じました、それは私があなたが経験しているかもしれない私の問題の本当の原因に私を導きました：Visual Studioのテスト実行はデフォルトで開いたままで、ファイルのロックを維持します。

主に役に立たない動作を停止するには、https：//connect.microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012-11-0の指示に従ってください。 -50727-1-rtmrel

[テスト]メニュー-> [テスト設定]-> [テスト実行エンジンを実行し続ける]をオフにします。

私の問題はdotnetがハングアップし、VSが新しいdllを作成するか、古いdllにアクセスしようとするたびに、dotnetプロセスがdllにラッチし、Visual Studioがdllのクローンを作成しなくなることでした。解決策は、タスクマネージャーですべてのdotnetタスクを終了することです（1つを終了しようとしていてシャットダウンしない場合、つまり、動作している場合、実際に削除されるのは、死んだものだけです）。

VisualStudioを閉じ、ctrl-alt-delete、タスクマネージャーを選択し、すべてのMSBuildプロセスを見つけて終了します-VisualStudioには基本的にかなり深刻なバグがあり、デバッガーの制御を失い、デバッガーはdebug / binの.pdbファイルのロックを維持しますフォルダ。すべてのMSBuild（デバッガー）プロセスを終了したら、/ debug / binフォルダーを削除し、Visual Studioでソリューションを再度開きます。あなたは今行ってもいいです。Microsoftはこのがらくたを修正する必要があります。

1つの更新後に同様の動作があったVS 2017に関する別の質問を開きました。問題は、ウイルス対策プログラムによって生成されたようです。

ウイルス対策の除外リストにbinフォルダーを追加し、マシンを再起動しましたが、動作するようです。

私はこの問題を解決しました。

デバッグの近くに、いくつかの構成を含むドロップダウンメニューが表示されます。デフォルトはAny CPUでした。x86を選択し、機能するプログラムを実行します。x86がない場合は、構成マネージャーに移動してx86を追加します

もう1つの陰謀、うーん、でもそれは簡単で、VS 2013で私のために機能します。プロジェクトをクリックします。プロパティパネルには、Project Fileという名前のエントリと値

（プロジェクト名）.vbproj

プロジェクト名を変更します（末尾に-01を追加するなど）。ロックされた元の.zipファイルはまだ残っていますが、参照されなくなったため、作業を続行できます。次回コンピュータを再起動すると、そのロックは解除され、誤ったファイルを削除できます。