プロジェクトをデバッグすると、次のエラーが発生します。
「ファイル「obj\Debug\MyDream.exe」を「bin\Debug \MyDream.exe」にコピーできません。別のファイルが使用しているため、プロセスはファイル「bin \ Debug\MyDream.exe」にアクセスできません。処理する。"
Process Explorerを使用すると、MyApplication.exeが出ていたことがわかりますが、以前にデバッグを停止したにもかかわらず、システムプロセスはまだそれを使用しています。コードを変更してデバッグを開始するたびに、それが発生します。プロジェクトをUSBにコピーしてデバッグすると、正常に実行されます。
なんで？このエラーを修正するにはどうすればよいですか？
私はWindow7Professionalを使用しています。Xpでは、このエラーが発生したことはありません。
うーん、これは古い問題であり、VisualStudioで時々発生する問題です。それは私を数回噛みました、そして私はVSで再起動して戦う時間を失いました。ここでSOについて何度も議論されていると思います。これは、MSDNフォーラムでも話題になっています。実際の解決策はありませんが、いくつかの回避策があります。ここから調査を開始します。
何が起こっているのかというと、VSはファイルのロックを取得していて、それを解放していません。皮肉なことに、そのロックはVS自体がファイルを削除するのを防ぎ、アプリケーションを再構築するときにファイルを再作成できるようにします。唯一の明らかな解決策は、VSを閉じて再起動し、ファイルのロックを解除することです。
私の最初の回避策は、bin / Debugフォルダーを開き、実行可能ファイルの名前を変更することでした。ロックされている場合は削除できませんが、名前を変更することはできます。したがって、最後などに数字を追加するだけで、すべてのウィンドウを閉じてVSが再起動するのを待たずに作業を続けることができます。一部の人々は、ビルド前のイベントを使用してこれを自動化し、古い出力ファイル名の最後にランダムな文字列を追加しています。はい、これは巨大なハックですが、この問題は非常に苛立たしく衰弱させるため、何でもできます。
後で、もう少し実験した後、問題は、デザイナーの1人を開いた状態でプロジェクトをビルドしたときにのみ発生するように見えることを学びました。したがって、長期にわたって機能し、これらのばかげたエラーの1つに再び対処することを妨げた解決策は、WinFormsプロジェクトをビルドする前に、常にすべてのデザイナーウィンドウを閉じるようにすることです。はい、これもやや不便ですが、VSを1時間に2回以上再起動する必要があることは間違いありません。
これはWPFにも当てはまると思いますが、私はWPFを使用しておらず、個人的に問題を経験したことはありません。
また、VS2012RCでの再現もまだ試していません。まだ修正されているかどうかはわかりません。しかし、これまでの私の経験では、Microsoftが修正したと主張した後でも、なんとかポップアップすることができます。VS2010SP1にはまだあります。もちろん、彼らのプログラマーが彼らが何をしているのかわからないばかだと言っているのではありません。バグの原因は複数あるか、実験室で確実に再現することは非常に難しいと思います。それは私が個人的にバグレポートを提出していないのと同じ理由です（私は他の人を+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でも同じ問題が発生しました。プロジェクトでこれが発生した原因はわかりませんが、ソリューションをクリーンアップして再構築することで修正できました。
これは古い質問だと思います。残念ながら、の.net core 2.0アプリケーションで同じ問題に直面していましたvisual studio 2017。それで、私は自分のために働いた解決策を共有することを考えました。この解決策の前に、私は以下の手順を試しました。
上記の手順のいずれも問題を修正しませんでした。
Task Manager次に、選択したプロセスを開き、dotnet[タスクの終了]ボタンをクリックしました。後でVisualStudioを開いたところ、すべてが正常に機能していました。
少なくとも私の場合、Visual Studio 2012が少なくとも2つのmsbuild.exeゴーストプロセスを作成していて、ビルド後に消滅しなかったことに気づきました。これらのゾンビが原因でファイルロックが発生しているようです。
msbuild.exeを強制終了することは、1回限りの解決策であり、ビルドごとに実行する必要があります。
しかし、並列ビルドを完全に無効にできることがわかりました-[ツール]>[オプション]>[プロジェクトとソリューション]>[ビルドと実行]>[並列プロジェクトビルドの最大数]に移動しました-デフォルトでは、値は8です。 1に切り替えました。チャームのように機能します。
もちろん、ビルドは少し遅くなりましたが、申し訳ありませんが安全です。少なくともこの特定の小さなプロジェクトでは、複数のビルドスレッドは必要ありませんでした。
単体テストの実行中にこの問題が発生した場合は、ここで私の回答を参照してください。以下にコピーされた回答：
Sébastienの回答に基づいて、テストプロジェクトにビルド前の手順を追加して、
vstest.*まだ実行中の実行可能ファイルを自動的に強制終了しました。次のビルド前のコマンドが機能しました。taskkill /f /im vstest.* exit 0実行中の実行可能ファイル
exit 0がない場合のビルドの失敗を防ぐために、コマンドは最後にあります。vstest.*
最近、同じエラーの説明でVisual Studio 2012に問題が発生しました：「ファイルが別のプロセスによって使用されているため、プロセスはファイルにアクセスできません...」
これを最初に修正するには、まだそれを使用しているアプリケーションを理解する必要があります。「MSBuild」や「MSBuildホスト」などのすべてのプロセスをシャットダウンしました。しかし、これだけでは不十分です。「コードコントラクト」をインストールしてオンにした場合、この操作をチェックしてハングアップするためにDLLが必要になることがあります。
したがって、「CCCheck.exe」のすべてのプロセスを停止する必要があり、それだけです。
最後に、プロセスがDLLを使用していることを理解するために、ファイルマネージャで「obj」フォルダを削除しようとすると、この操作が失敗する場合があります。ハングした操作の説明が記載された「メッセージウィンドウ」が表示される場合があります。また、バリアントとして、「SysInternalsSuite」アプリケーションの使用を試みることができます。
私のために働いた。タスクマネージャ->プロジェクトの名前->タスクの終了。（私は私のプロジェクト名で3つの同じプロセスを持っていました）;
VS 2013; 8勝;
アプリケーションの以前の実行（たとえば、デバッグオプションなしで開始）が実際に停止していることを確認してください。私はWPFアプリケーションで作業していて、デバッグせずに開始し、エラーが発生し続けるときに最小化しました。アプリケーションを閉じた後、VSの動作は通常に戻りました。
私はVisualStudio2017でこの問題に悩まされてきました。この問題は、約2、3週間前に始まり、私の生産性にひどく食い込んでいます。CleanとRebulidは機能していません。私のマシンを再起動しても仕事はしません。
この問題に対処する1つの方法は、問題のあるアセンブリをクリーンアップし、すぐに実行するプロジェクトを（再構築するのではなく）ビルドすることです。これは約30％の時間で機能します。
ただし、おそらく私が見つけた最も信頼できる解決策は、開発者コマンドプロンプトを開いて、msbuild直接使用することです。私は過去3日間これを行ってきましたが、これまでのところ問題は一度も発生していません。
私の場合、「すべてのファイルを表示」を有効にしました。Visual Studio 2017
を実行しますtaskmanager。
それを見つけnetcoreて削除します。
その後、手動で、またはを実行してファイルを削除できますClean。
私はこの問題を解決しました。
デバッグの近くに、いくつかの構成を含むドロップダウンメニューが表示されます。デフォルトには任意のCPUがありました。x86を選択し、動作するプログラムを実行します。x86がない場合は、構成マネージャーに移動してx86を追加します
これは純粋な推測であり、答えではありません。
しかし、私はしばらくの間この問題を抱えています。
私はしばらくして、VSと私のAV予防策との相互作用を疑うようになりました。
いくつか遊んだ後、アンチウイルスを変更して、
C：\ Users [username] \ AppData \ Local \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies
フォルダはリアルタイム保護に含まれていませんでした。
ビルドが実際に最初にここにDLLを書き込み、次にそれを最終的なビルドの場所にコピーするように見えます。
手遅れかもしれません。しかし、私は同様の問題に遭遇し、私の場合、プロジェクトには自己参照がありました。したがって、参照からそれを削除することは魅力のように機能しました!!!
フォームを閉じたり、VisualStudioを再起動したりせずに、プロジェクトのコンパイルページに移動し、[高度なコンパイルオプション...]ボタンをクリックするのが最も簡単な方法です。次に、オプションの1つに変更を加え（たとえば、[デバッグ情報の生成]を[完全]から[pdbのみ]に変更）、[OK]をクリックします。これは毎回機能し、MSがこのバグを修正するまで実行する必要があります（VS2012からVS2013に切り替えるまでこの問題は発生していません）
別の注意点として、プロジェクトまたはソリューションをクリーンアップできない場合、ビルドされません。ファイルはVSによって確実にロックされています（少なくとも私の場合は、ウイルス対策の問題ではありません）
私はこれらすべての提案と他の場所で見つかった他の提案を試しましたが、私にとってうまくいったのはコンピューターを再起動することだけでした。次に、クリーンなソリューションを実行した後、再構築しました。参考までにVisualStudio2013を使用しています。
私はこれと同じ問題に遭遇しました、そして私が見つけたのは実際にバックグラウンドで複数のWindowsフォームアプリケーションを実行しているということです。これは、アプリケーションに2つのフォームがあり、メインフォームではない2番目のフォームを閉じて、アプリケーションが完全に終了しない場合に発生します。
私は通常、アプリケーションを実行します
解決策は、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 / A*">次に再構築
Cody Grayの回答は、一部の人が経験している可能性のある問題の本当の原因に私を導いてくれたという点で、部分的に役立ちました。VisualStudioのテスト実行はデフォルトで開いたままで、ファイルのロックを維持します。
その主に役に立たない動作を停止するには、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にラッチし、VisualStudioがdllのクローンを作成するのを停止することでした。解決策は、タスクマネージャーですべてのdotnetタスクを終了することです（1つを終了しようとしてシャットダウンしない場合、つまり機能している場合、実際にはデッドタスクのみが削除されます）。
VisualStudioを閉じ、ctrl-alt-delete、タスクマネージャーを選択し、すべてのMSBuildプロセスを見つけて終了します-VisualStudioには基本的にかなり深刻なバグがあり、デバッガーの制御が失われ、デバッガーがdebug/binの.pdbファイルのロックを維持しますフォルダ。すべてのMSBuild（デバッガー）プロセスを終了したら、/ debug / binフォルダーを削除し、VisualStudioでソリューションを再度開きます。あなたは今行ってもいいです。Microsoftはこのがらくたを修正する必要があります。
1回の更新後に同様の動作をしたVS2017に関する別の質問を開きました。ただし、問題はウイルス対策プログラムによって発生したようです。
binフォルダーをアンチウイルス除外リストに追加し、マシンを再起動しましたが、動作しているようです。
私は同じ問題に直面しましたが、上記の答えはどれも私を助けませんでした！Visual Studio 2017を閉じてから再実行するだけで、機能しました。
もう1つの厄介な問題ですが、VS2013では簡単でうまくいきます。プロジェクトをクリックしてください。プロパティパネルには、値を持つProjectFileという名前のエントリが必要です。
（プロジェクト名）.vbproj
プロジェクト名を変更します-末尾に-01を追加するなど。ロックされた元の.zipファイルはまだ存在しますが、参照されなくなります...作業を続行できます。次回コンピュータを再起動すると、そのロックが解除され、誤ったファイルを削除できます。