エラー：別のプロセスで使用されているため、ファイル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を再起動して戦うのに何時間も費やしました。ここでSOで何度も議論されていると思います。また、MSDNフォーラムでも話題になっています。実際の解決策はありませんが、いくつかの回避策があります。 ここで調査を開始 。
何が起こっているのかというと、VSはファイルのロックを取得し、それを解放していません。皮肉なことに、このロックはVS自体がファイルを削除することを防ぎ、アプリケーションを再構築するときにファイルを再作成できるようにします。唯一の明らかな解決策は、VSを閉じて再起動し、ファイルのロックを解除することです。
私の最初の回避策は、bin/Debugフォルダーを開き、実行可能ファイルの名前を変更することでした。ロックされている場合は削除できませんdeleteが、名前を変更できます。したがって、最後または何かに数字を追加するだけで、すべてのウィンドウを閉じてVSの再起動を待つことなく作業を続けることができます。 一部の人々は、ビルド前イベントを使用してこれを自動化さえしています 古い出力ファイル名の最後にランダムな文字列を追加します。はい、これはgiantハックですが、この問題は非常にイライラさせられ、衰弱させてしまいます。
少し実験を重ねた結果、デザイナーの1人が開いている状態でプロジェクトをビルドした場合にのみ問題が発生するように見えることを後で知りました。そのため、長期にわたって機能し、これらの愚かなエラーの1つに再び対処するのを妨げていたソリューションは、WinFormsプロジェクトをビルドする前に、すべてのデザイナーウィンドウを常に閉じるようにすることです。はい、これもやや不便ですが、VSを1時間に2回以上再起動する必要がないため、ズボンに勝ります。
これはWPFにも当てはまると思いますが、私はそれを使用せず、個人的には問題を経験していません。
また、VS 2012 RCで再現することもまだ試みていません。まだ修正されているかどうかはわかりません。しかし、これまでの私の経験では、Microsoftがそれを修正したと主張した後でも、何とかポップアップすることができました。 VS 2010 SP1にはまだあります。もちろん、彼らのプログラマーは、彼らが何をしているのか知らない馬鹿だと言っているのではありません。バグには複数の原因があるだけでなく、実験室で確実に再現することは非常に難しいと考えています。これは、Abominable Snowmanのように信頼できる方法で再現できないため、バグレポートを個人的に提出していないのと同じ理由です（他の人を+1しましたが）。
<特に誰にも向けられていない暴言>
Visual Studio 2008でさえ、以前にこのエラーが発生しました。それはVisual Studio 2012で再び発生しました。
これが私がやることです。
面倒なプロジェクトのビルド前イベントにこれを貼り付けます：
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
コンピューター（右クリック）->管理->サービスとアプリケーション->サービス->アプリケーションエクスペリエンスを有効にする
私のために働いた！
Visual Studio 2013でも同じ問題が発生しました。プロジェクトでこれが発生した原因はわかりませんが、ソリューションをクリーンアップして再構築することで修正できました。
- ビルド>クリーンソリューション
- ビルド>ソリューションのリビルド
少なくとも私の場合、Visual Studio 2012が少なくとも2つのmsbuild.exeゴーストプロセスを作成していることに気づきましたが、ビルド後に消滅することはありませんでした。これらのゾンビは、明らかにファイルロックを引き起こしています。
Msbuild.exeを強制終了することは1回限りのソリューションであり、ビルドごとに実行する必要があります。
しかし、私は一度並列ビルドを無効にすることができることを理解しました-ツール>オプション>プロジェクトとソリューション>ビルドと実行>「並列プロジェクトビルドの最大数」に行きました-デフォルトでは8の値を持っています1に切り替えました。チャームのように機能します。
もちろん、ビルドは少し遅くなりましたが、申し訳ありませんが安全です。少なくともこの特定の小規模プロジェクトでは、複数のビルドスレッドは必要ありませんでした。
これは古い質問です。残念ながら、.net core 2.0のvisual studio 2017アプリケーションで同じ問題に直面していました。だから、私は私のために働いたソリューションを共有することを考えました。このソリューションの前に、以下の手順を試しました。
- Visual Studioを再起動しました
- すべてのアプリケーションを閉じました
- ソリューションをクリーンアップして再構築する
上記の手順のどれも問題を解決しませんでした。
そして、Task Managerを開き、dotnetプロセスを選択して、[タスクの終了]ボタンをクリックしました。後でVisual Studioを開いたところ、すべてが正常に機能していました。
単体テストの実行中にこの問題が発生している場合は、私の答え here を参照してください。以下にコピーした回答：
セバスチャンの答えに基づいて、テストプロジェクトにビルド前のステップを追加して、実行中の
vstest.*実行可能ファイルを自動的に強制終了します。次のビルド前コマンドが機能しました：taskkill /f /im vstest.* exit 0
exit 0コマンドは最後にあり、vstest.*実行可能ファイルが実行されていない場合のビルドの失敗を防ぎます。
アプリケーションの以前の実行（たとえば、デバッグオプションなしで開始）が実際に停止していることを確認します。私はWPFアプリケーションで作業していましたが、デバッグなしで起動し、エラーが発生し続けたときに最小化されました。アプリケーションを閉じた後、VSの動作は正常に戻りました。
私のために働いた。タスクマネージャ->プロジェクトの名前->タスクの終了。 （プロジェクト名に同じプロセスが3つありました）;
VS 2013;勝利8;
最近、同じエラーの説明でVisual Studio 2012で問題が発生しました：「プロセスは別のプロセスで使用されているため、ファイルにアクセスできません...」
これを最初に修正するには、まだ使用しているアプリケーションを理解する必要があります。 「MSBuild」や「MSBuild Host」などのすべてのプロセスをシャットダウンしました。しかし、これでは十分ではありません。 「コードコントラクト」をインストールしてオンにした場合、DLLがこの操作をチェックしてハングアップすることがあります。
したがって、「CCCheck.exe」のすべてのプロセスを停止する必要があります。それだけです。
最後に、プロセスがDLLを使用していることを理解するために、常にファイルマネージャーで「obj」フォルダーを削除しようとすると、この操作は失敗します。操作。また、バリアントとして、「Sys Internals Suite」アプリケーションの使用を試みることができます。
私の場合、「すべてのファイルを表示」を有効にしているということでした。 Visual Studio 2017
私はVisual Studio 2017でこの問題に悩まされています。約2、3週間前に始まり、私の生産性に大きく影響しました。 CleanとRebulidは機能していません。マシンを再起動しても機能しません。
この問題に対処する1つの方法は、問題のあるアセンブリをクリーンアップし、すぐに実行するプロジェクトを（再構築ではなく）ビルドすることです。これは、約30％の時間で機能します。
ただし、おそらく最も信頼できるソリューションは、開発者コマンドプロンプトを開き、msbuildを直接使用することです。私は過去3日間これを行ってきましたが、これまでのところ問題は一度も発生していません。
taskmanagerを実行します。netcoreを見つけて削除します。
その後、手動でまたはCleanを実行してファイルを削除できます。
cody Grayの答えは部分的に役立つことがわかりました。それは、あなたの一部が経験しているかもしれない私の問題の本当の原因に私を向けてくれたからです。
主に役に立たない動作を停止するには、 https://connect.Microsoft.com/VisualStudio/feedback/details/771994/vstest-executionengine-x86-exe-32-bit-not-closing-vs2012の指示に従ってください-11-0-50727-1-rtmrel
[テスト]メニューのチェックを外します-> [テスト設定]-> [テスト実行エンジンの実行を維持]
[解決済み]エラー：ファイルbin/Debug/...にアクセスできません。別のプロセスで使用されているためです：
最初にフォームをロードし、その後自動的に消えて、2番目のフォームが画面にロードされるなど、2つのウィンドウフォームを次々に実行しようとすると、このエラーが発生することに近づいています。
基本的に、バックグラウンドで実行されている最初のフォームと、このエラーの背後にある主な理由を閉じる必要があります。
最初のフォームを閉じるには、これら2行のコードを2番目のフォームロードイベントハンドラーに追加する必要があります。
Form1 form = new Form1();
form.Close();
これにより、エラーが完全に解決されます。
フォームを閉じたりVisualStudioを再起動したりしない最も簡単な方法は、プロジェクトのコンパイルページに移動し、[高度なコンパイルオプション...]ボタンをクリックすることです。次に、オプションのいずれかに変更を加え（たとえば、[デバッグ情報の生成]を[完全]から[pdbのみ]に変更する）、[OK]をクリックします。毎回動作し、MSがこのバグを修正するまで実行する必要があります（VS2012からVS2013に切り替えるまで、この問題が発生したことはありません）
別の注意点として、プロジェクトまたはソリューションをクリーンアップできない場合、ビルドされません。ファイルはVSによって確実にロックされます（少なくとも私の場合はウイルス対策の問題ではありません）
VisualStudioを閉じ、ctrl-alt-delete、タスクマネージャーを選択、すべてのMSBuildプロセスを見つけて終了-VisualStudioには基本的に非常に深刻なバグがあり、デバッガーの制御を失い、デバッガーはデバッグ/ビンの.pdbファイルのロックを維持しますフォルダ。すべてのMSBuild（デバッガー）プロセスを終了したら、/ debug/binフォルダーを削除し、Visual Studioでソリューションを再度開きます。あなたは今行ってもいいです。 Microsoftはこのがらくたを修正する必要があります。
遅すぎるかもしれません。しかし、私は同様の問題に遭遇し、私の場合、プロジェクトには自己参照がありました。したがって、参照から削除するのは魅力的でした!!!
1つの簡単な解決策は、bin\Debugフォルダーに移動し、そのフォルダー内のすべてのファイルを削除してから再構築することです。動作しない場合は、Visual Studioを閉じて、エクスプローラーを使用してbin\Debugフォルダーに移動し、左側の[ファイル]> [コマンドプロンプトを開く]> [管理者としてコマンドプロンプトを開く]をクリックし、このコマンド「DEL/F/Q/A * ">その後再構築
ビルド前コマンド
(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)
助けた
これは単なる推測であり、答えではありません。
しかし、私はしばらくの間この問題を抱えていました。
VSと私のAV予防措置との相互作用を疑うためにしばらくしてから来ました。
いくつかプレイした後、ウイルス対策プログラムを変更したときにmayがなくなってしまい、
C：\ Users [ユーザー名]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies
フォルダーはリアルタイム保護に含まれていません。
ビルドが実際に最初にDLLをここに書き込んでから、最終的なビルドの場所にコピーするように見えます。
私の問題は、ドットネットがハングアップし、VSが新しいdllを作成するか、古いDLLにアクセスしようとするたびに、ドットネットプロセスがdllにラッチし、Visual Studioがdllのクローンを作成するのを停止しました。解決策は、タスクマネージャーですべてのドットネットタスクを終了することです（終了しようとしてシャットダウンしない場合にのみ、実際に死んだタスクを削除します）。
私はこれらのすべての提案と他の場所で見つかった他の提案を試みましたが、私のために働いた唯一のことはコンピュータを再起動することでした。その後、クリーンなソリューションを実行した後、再構築しました。参照用にVisual Studio 2013を使用しています。
私はこれと同じ問題に遭遇しましたが、私が見つけたのは実際に複数のWindowsフォームアプリケーションを実行しているがバックグラウンドにあることです。アプリケーションに2つのフォームがあり、メインフォームではない2番目のフォームを閉じると、アプリケーションが完全に終了しません。
通常、アプリケーションを実行します
- そのexeまたは
- デバッグせずに実行する
ソリューションは、Windowsフォームアプリケーションの他のインスタンスに近い。これは one アプリケーションインスタンスを常に閉じる方法です。
VS 2017に関して 個別の質問 を開きましたが、1回の更新後に同様の動作をしました。ただし、問題はウイルス対策プログラムによって生成されたようです。
アンチウイルス除外リストにbinフォルダを追加し、マシンを再起動したところ、動作するようになりました。