Visual Studioのビルドが失敗する:obj \ debugからbin \ debugにexeファイルをコピーできない


193

更新: このバグを再現するサンプルプロジェクトは、Microsoft Connectにあります。また、以下の承認された回答で提供されているソリューションがそのサンプルプロジェクトで機能することをテストして確認しました。この解決策がうまくいかない場合は、おそらく別の問題が発生しています(別の質問に属しています)。


これは以前スタックオーバーフローと他の場所の両方で尋ねられた質問ですが、これまでに見つけた提案のどれも私を助けてくれなかったので、私は新しい質問をしてみなければなりません。

シナリオ:単純なWindowsフォームアプリケーション(C#、. NET 4.0、Visual Studio 2010)があります。他のほとんどのフォームが継承する2つの基本フォームがあり、データベースアクセスにEntity Framework(およびPOCOクラス)を使用します。派手なもの、マルチスレッドなどはありません。

問題:しばらくの間はすべて順調でした。その後、突然、アプリケーションを起動しようとしたときにVisual Studioがビルドに失敗しました。「ファイル '... bin \ Debug \ [ProjectName] .exe'を削除できません。パス '... bin \ Debug \ [ProjectName] .exe'へのアクセスが拒否されました。」という警告が表示されました。エラー「ファイル 'obj \ x86 \ Debug \ [ProjectName] .exe」を「bin \ Debug \ [ProjectName] .exe」にコピーできません。プロセスはファイル' bin \ Debug \ [ProjectName] .exe」にアクセスできません'別のプロセスで使用されているためです。」(Rebuildを実行すると警告とエラーの両方が表示されますが、Buildを実行するとエラーのみが表示されます-関係ないと思いますか?)

私は警告とエラーメッセージが何を言っているかを完全に理解しています:Visual Studioは、なぜか何らかの理由で同時にロックがかかっている間に、exeファイルを上書きしようとしています。ただし、これは問題の解決策を見つけるのに役立ちません... Visual Studioをシャットダウンして再起動することだけが機能していることがわかりました。その後、いくつかのフォームに変更を加えるまで、ビルドと起動は機能します。その後、同じ問題が発生し、再起動する必要があります...かなりイライラします!

上で述べたように、これは既知の問題であると思われるため、推奨される解決策はたくさんあります。ここですでに試したものをリストアップするだけなので、人々は何をスキップすべきかを知っています。

  • 新しいクリーンソリューションを作成し、古いソリューションからファイルをコピーするだけです。
  • 以下をプロジェクトの事前ビルドイベントに追加します。

    if exist "$(TargetPath).locked" del "$(TargetPath).locked"
       if not exist "$(TargetPath).locked" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked"
  • 以下をプロジェクトプロパティ(.csprojファイル)に追加します。

    <GenerateResourceNeverLockTypeAssemblies>true</GenerateResourceNeverLockTypeAssemblies>

しかし、どれも私にとってはうまくいかなかったので、なぜ私が少しイライラし始めているのかを理解できるでしょう。他にどこを見ればよいのかわからないので、誰かが私に何かを与えることを願っています!これはVSのバグですか?ある場合、パッチはありますか?または、何か間違ったことをしたことがありますか?循環参照などがありますか?

どんな提案も大歓迎です:)

更新:としては、以下のコメントで述べた私もそれが実際にそのプロセスExplorerを使用してチェックしたあるファイルをロックしているVisual Studioの。


4
アプリケーションが正しく終了するかどうかを確認しましたか?タスクマネージャはプロセスのリストに[ProjectName] .exeを表示しますか?
miensol

2
以前にこれを使用したことがあり、ファイルの名前を.oldなどに変更して、ビルドを再実行しました。私が知っている正確な修正ではありませんが、それは私のために働いた。
codedbadger

@miensol:はい、正しく閉じているようです。「プログラム '[1848] [ProjectName] .vshost.exe:Managed(v4.0.30319)'がコード0(0x0)で終了しました。」と表示されます。@Barry:bin \ Debug内のexeファイルの名前を変更することは機能しますが、あなたが言ったように、それは実際の解決策ではなく、毎回行う必要があるのはかなり面倒です。ただし、Visual Studioを再起動するより少し良い...
Julian

2
@Naliluj:リソースファイルに関連している可能性があることを説明するマイクロソフトフォーラムからこの記事を見つけました。resxファイルを使用している場合、これがヒントになることがあります。
Patrick

1
後世のために、私はこの問題を抱えていましたが、csprojファイルに<GenerateResourceNeverLockTypeAssemblies> true </ GenerateResourceNeverLockTypeAssemblies>要素を追加することで解決しました。
ThisIsTheDave

回答:


117

これは愚かに聞こえるでしょうが、私はこれらのソリューションをすべて試して、VS2010をWindows 7で実行しました。名前を変更したりビルドしたりする以外はどれも機能しませんでした。結局、私は犯人を突き止めましたが、信じられないほどです。しかし、私はAssemblyInfo.csで次のコードを使用していました...

[assembly: AssemblyVersion("2.0.*")]

これはかなり一般的ですが、何らかの理由でバージョンを2.0.0.0に変更すると、問題が解決しました。それがWindows 7固有のものかどうか(私は3〜4週間しか使用していません)か、それともランダムか、または何であるかはわかりませんが、修正されました。VSは生成した各ファイルのハンドルを保持していたと思います。そのため、物事をインクリメントする方法を知っているのでしょうか。私は本当に確信が持てず、これが起こるのを見たことがない。しかし、他の誰かが自分の髪を抜いている場合も、試してみてください。


12
それはクレイジーなアイデアの1つです。それをお伝えします;)さらにクレイジーなのは、実際に機能しているように見えることです。これを何度かテストしましたが、「2.0。*」などのアセンブリバージョンを使用するとエラーが発生することを確認できますが、「2.0.0」を使用するとチャームとして機能します。これをテストすることをもっと多くの人々に要請し、それが機能しているのを見つけたら、この答えに投票してください。これは知っておく必要があることです!Microsoftがこれを取り上げてくれることを願っています... drharrisに感謝します:)
Julian

2
これは私にとってはうまくいきませんでした。VSを再起動すると、しばらくの間エラーが発生しませんでした。このエラーが発生するたびに、VS 2010を再起動する必要があります
Sharique

6
ファイ...これは私にはうまくいきませんでした。私の設定は常に:[assembly:AssemblyVersion( "1.0.0.0")] [assembly:AssemblyFileVersion( "1.0.0.0")]
tbone

4
現在[assembly:AssemblyVersion( "1.0.0.0")]がある場合は、[assembly:AssemblyVersion( "2.0.0.0")]に置き換えます(つまり、「1」ではなく「2」)。それは私のために働いた。確認していませんが、バージョンを現在のバージョン以外に変更するだけでこの問題を解決できる可能性があります。
フレデリック

1
DLLでも動作します!VSはdllをコピーできないと言い、[アセンブリ:AssemblyVersion]と[アセンブリ:AssemblyFileVersion()]の両方を1.0。*から2.0.0.0に変更した後、それは機能しました。
AZ。

14

この問題についてこれ以上フィードバックを得ていないので、結局のところ私の解決策を共有したいと思いました。

元の投稿へのコメントでバリーが示唆したように、手動で'... bin \ Debug [ProjectName] .exe'を別の名前に変更します(例:'[ProjectName] 1.exe')が1つの回避策です(私はただし、自分でファイルを削除することは許可されていません。同じロックで削除を防止すると名前の変更もできないので、少し変だと思います...)。これは良い解決策ではありませんが、妥当な速さであり(少なくとも数回実行した後は、ほぼ日常的な作業になります)、少なくともVisual Studioを再起動するよりもはるかに高速です。

誰かが不思議に思った場合に備えて、私はこの問題を半ランダムにしか見ないことも付け加えることができます。これは通常、フォームのデザインモードでいくつかの変更を加えた後に発生します(ただし、常にではありません)。ビジネスロジックコードまたは非ビジュアル関連コードのみを変更する場合、通常は発生しません(ただし、変更する場合もあります...)。確かにイライラしますが、少なくとも私にはうまくいくハックがあります-次のプロジェクトでもこの問題に直面しないことを願いましょう...

@Barry:コメントのクレジットを取得したい場合は、お気軽に回答として投稿してください。


これは私が過去にやったことなので、私はこれに投票しました。私は同意します、それは汚い解決策ですが、それは機能します。VSはこの問題を数回繰り返してきました。ネットワークディレクトリからもプロジェクトを読み込んでいます。完全に信頼されていますが、問題ではありません。ドライブマッピングでもUNCでもかまいません。ええ、MSは本当にこれを修正する必要があります。彼らはそれを再現することができないというそれのための閉じたバグを持っています。ラメ!
Josh Robinson

14

プロジェクトフォルダーとサブフォルダーのWindowsインデックスサービスを無効にするだけの簡単な解決策が1つ見つかりました


2
これも私にとってはうまくいきました。プロセスエクスプローラーがdevenv.exeがロックハンドルを保持していることを示したので、なぜか理解できません。それでも、インデックス作成をオフにすると問題が解決しました。
Fopedush 2014年

1
@Fopedush同じ問題でこの問題に遭遇しましたが、そのときはこの質問を見ていませんでした。この回答には、なぜそれが役立つのかについての説明があります。
ダレンヘイル2014

1
これは私のためにそれをやった。
マーティンカポディッチ2014年

12

VS2008(Windows 7 x32)のWPFプロジェクトで同じ問題(MSB3021)があります。前回の実行後にアプリケーションをすばやく再実行しようとすると、問題が発生します。数分後、exeファイルが自動的にロック解除され、アプリケーションを再実行できます。しかし、そのような長い休止は私を怒らせます。 私を本当に助けた唯一のことは、VSを管理者として実行することでした。


1
この問題に関する最近のバグレポートを見つけました:connect.microsoft.com/VisualStudio/feedback/details/558848/…そのバグレポートは、バグを再現できるサンプルプロジェクトを提供しました。drharrisによって提案されたソリューションもそこで機能しました(サンプルプロジェクトの段階的なソリューションについては、上記のリンクに投稿された回避策を参照してください)。
ジュリアン

これは私にとっても有効な唯一のソリューションです。ありがとう@Nailuj!
ウィンガー

これは、VSを再起動するよりも確かに簡単です。
Elvedin Hamzagic 2015年

1
接続の問題で「ページが見つかりません」、恥ずかしさから削除しただけ= Sこれまでに投稿された解決策/回避策はありましたか?
Coops、2015年

9

この問題に遭遇したとき、ビルドしようとしているプロジェクトがobjフォルダー内の.exeをロックするソリューションのスタートアッププロジェクトとして設定されているという事実に関係しています(タスクマネージャーにも表示されます)。ソリューション内の別のプロジェクトを右クリックして、スタートアッププロジェクトの設定を選択します。これでロックが解除され、タスクマネージャから削除され、ビルドできるようになります。


1
これは毎回うまくいきます。生成されてサービス用に開始されたvshostプロセスに関係しているようです
jaywayco 2013年

8

私はここで他のすべての提案を試しましたが、どれもうまくいきませんでした。最終的に、私はプロセスモニターを使用して、VS2010が構築に失敗した.exeがシステムプロセス(PID = 4)によってロックされていることを発見しました。これを含む状況についてSOを検索すると、この答えが得られました。

要約:Application Experienceサービスを無効にした場合(私が行ったように)、再度有効にして開始します。2年間の悪化は終わりました。


+1私は以前に他のすべてを試しました(1.タスクマネージャ、2。プロセスエクスプローラ、つまりウィンドウで許可されないクローズハンドル、3。ウイルス対策を無効にする、4。WindowsインデックスサービスからAPP_DATA / Local / Microsoft / Visual Studioを除外しました。 )しかし、このヒントre:「アプリケーションエクスペリエンス」サービスは、壁に頭をぶつけてしまうのを防いだ唯一のサービスです。それを有効にすると、問題はなくなりました。面白いことに、私がそれを再び無効にした後、すべてがまだ大丈夫でした。これ以上問題はありませんでした。しかし、間違いなくこれが私のためにそれを分類した唯一のものです。
トマス・

私のためにも働きます!!! 動作する他の唯一のものは、アプリケーションを実行する前にbinフォルダーを削除することですが、実行する前に常に削除する必要があり、非常に煩わしいです。
E_Blue 2016年

6

私もこれと非常によく似た問題を抱えており、私の場合は、bin \ debugフォルダーをVMwareの下の共有フォルダー、およびVMware、VMゲストの下のエクスプローラー、あるいはウイルス対策の共有フォルダーとして使用可能にしたことが原因であることがわかりましたゲストの下のプログラム(インストールされているとは思いませんが)がファイルへのハンドルを保持していました。


アバストをインストールしましたが、今朝、dllにウイルスが含まれているというランダムなMVCエラーが発生しました。エラーの後、MVCプロジェクトをビルドできなくなりました。アバストファイルシステムシールドに例外を追加しましたが、すべてが再び機能します。
Dustyは


4

Process Explorerどのプロセスがファイルをロックしているかを正確に調べるために、ダウンロードをお勧めします。次の場所にあります。

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx


私は同意します-ファイルをロックしているのは必ずしもVSではありません。ウイルスチェッカーはこれを犯す可能性があります。ウイルスチェッカーをオフにして、効果があるかどうかを確認してください。
10

申し訳ありませんが、私はすでにそれを実行したことを忘れていました。そして、それはファイル([ProjectName] .vshost.exe)をロックしているVisual Studio(devenv.exe)であると述べています。だからそれも私にはあまり役に立たない。
ジュリアン

@ShellShock:アンチウイルス(Avast)を無効にしても効果はありません。
ジュリアン

私にとっては、Sysinternals ProcessExplorerを使用すると、そのファイルのハンドルが表示されますが、それをクリックすると、それを保持しているアプリケーションが表示されず、ハンドルを閉じようとすると、「エラーオープンプロセス:ハンドルが無効。" ProcessExplorerのエラー。それでもロックは持続します。
tbone

4

Visual Studioを使用して、エラーを再現する簡単なプロジェクトを思いつくことはできませんでした。

私の解決策は、Visual Studio Hostingプロセスを無効にすることでした。

興味がある人のために、問題のハンドルのハンドルトレースを添付しました。

0:044> !htrace 242C
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x000000007722040a: ntdll!ZwCreateFile+0x000000000000000a
0x0000000074b4bfe3: wow64!whNtCreateFile+0x000000000000010f
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0066: ntdll_773b0000!NtCreateFile+0x0000000000000012
0x000000007541b616: KERNELBASE!CreateFileW+0x000000000000035e
0x0000000075b42345: KERNEL32!CreateFileWImplementation+0x0000000000000069
0x000000006a071b47: mscorwks_ntdef!StgIO::Open+0x000000000000028c
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x00000000000006cc, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
0x0000000075b427b5: KERNEL32!RegOpenKeyExW+0x0000000000000021
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130
--------------------------------------
Handle = 0x000000000000242c - CLOSE
Thread ID = 0x0000000000000cd4, Process ID = 0x0000000000001a5c

0x000000007721ffaa: ntdll!ZwClose+0x000000000000000a
0x0000000074b3f2cd: wow64!whNtClose+0x0000000000000011
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x000000007724d177: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bfe4
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773cf992: ntdll_773b0000!ZwClose+0x0000000000000012
0x0000000075b42642: KERNEL32!BaseRegCloseKeyInternal+0x0000000000000041
0x0000000075b425bc: KERNEL32!RegCloseKey+0x000000000000007d
0x0000000068f13ca3: mscorlib_ni+0x0000000000233ca3
0x0000000069bc21db: mscorwks_ntdef!CallDescrWorker+0x0000000000000033
0x0000000069be4a2a: mscorwks_ntdef!CallDescrWorkerWithHandler+0x000000000000008e
--------------------------------------
Handle = 0x000000000000242c - OPEN
Thread ID = 0x0000000000001cd0, Process ID = 0x0000000000001a5c

0x0000000077220e0a: ntdll!NtOpenKeyEx+0x000000000000000a
0x0000000074b5d1c9: wow64!Wow64NtOpenKey+0x0000000000000091
0x0000000074b5313b: wow64!whNtOpenKeyEx+0x0000000000000073
0x0000000074b3cf87: wow64!Wow64SystemServiceEx+0x00000000000000d7
0x0000000074ac276d: wow64cpu!TurboDispatchJumpAddressEnd+0x0000000000000024
0x0000000074b3d07e: wow64!RunCpuSimulation+0x000000000000000a
0x0000000074b3c549: wow64!Wow64LdrpInitialize+0x0000000000000429
0x00000000772184c8: ntdll!LdrpInitializeProcess+0x00000000000017e2
0x0000000077217623: ntdll! ?? ::FNODOBFM::`string'+0x000000000002bea0
0x000000007720308e: ntdll!LdrInitializeThunk+0x000000000000000e
0x00000000773d0fca: ntdll_773b0000!NtOpenKeyEx+0x0000000000000012
0x0000000075b42721: KERNEL32!LocalBaseRegOpenKey+0x000000000000010c
0x0000000075b428c9: KERNEL32!RegOpenKeyExInternalW+0x0000000000000130

--------------------------------------
Parsed 0x358E stack traces.
Dumped 0x7 stack traces.
0:044> !handle 242c ff
Handle 242c
  Type          File
  Attributes    0
  GrantedAccess 0x120089:
         ReadControl,Synch
         Read/List,ReadEA,ReadAttr
  HandleCount   2
  PointerCount  3
  No Object Specific Information available

質問の一番上にある場合は、バグレポートとエラーを再現するサンプルプロジェクトを含むMicrosoft Connectへのリンクがあります。connect.microsoft.com
Julian

ホスティングプロセスを無効にするとうまくいきました。再度有効にした後も引き続き機能します。私はこの問題を解決するために4時間かけて何百もの解決策を試しました。これは、リモートで動作するように見えた唯一のものです。
ドリュー

4

問題がまだ解決されていない場合:

Visual Studioのエラーは:

「プロセスはファイル 'bin \ Debug ** app.exe **'にアクセスできません。別のプロセスによって使用されているためです。」

したがって、Windowsのタスクマネージャーに移動し(Ctrl + Shift + Esc)、アプリケーション名を見つけて、Endproccesで強制的に閉じます。


3

ここに別の可能性があります:

vs2012 / win7でこのエラーを受け取った後、私は行ってbinディレクトリのファイルを削除しようとしましたが、エクスプローラーはそのファイルがXAML UIデザイナーで使用中であることを示しました。

VSで開いていたすべてのタブを閉じ、VSを閉じてから、タスクマネージャーですべてのMSBuildプロセスを強制終了しました。最後に、VSを再起動した後、ソリューションを構築することができました。


そして別の考えられる原因:

この問題には別の原因が考えられます。いくつかのコードリファクタリングを実行し、プロジェクトをソリューションの内外に移動した後、私のプロジェクト参照はソリューション内のプロジェクトを期待どおりに参照しなくなりました。

この誤解を招くビジュアルスタジオは、複数のプロジェクトを同時にビルドして、ファイルロックを作成する可能性があると考えています。

編集:これはVS2012で最近でも数回発生しましたが、ビルド順序を正しい依存関係に設定し、VSが実行したままにしたmsbuildプロセスを強制終了してVSを再起動すると修正されます。念のため、msbuildプロセスを強制終了しますが、VSを閉じると、それらも強制終了されます。

これを引き起こすために私が通常行うことは、最後のビルドで参照していなかったソリューション内の別のプロジェクトに依存するようにプロジェクトをリファクタリングすることです。これはVSを混乱させる場合があり、ビルド順序を更新しません。

ビルド順序を確認するには:ソリューションエクスプローラーでソリューションを右クリックし、[プロジェクトのビルド順序...]を選択して、各プロジェクトの依存関係が適切に記述されていることを確認します。


私たちは最近、これをWinPhone 8プロジェクトで体験しました。どういうわけか、原因はタプル型を使用していた。タプルを使用したコードを削除すると、問題は解消しました。返された問題を元に戻すコードを追加します。
Seamus

私はVS2012で同じ問題を抱えていましたが、VSを閉じてもうまくいきませんでした-すべてのmsbuild.exeタスクを手動で強制終了する必要があります
mizzle

私はVS 2013を使用していて、各ビルドの前にタスクマネージャーで "XDesProc.exe * 32"プロセス(Microsoft Visual Studio XAML UI Designer)を強制終了することができましたが、それでうまくいきました。* .xamlファイルをデザインビューで開くたびにXAML UIデザイナーがリロードするように見えるため、VSを再起動する必要はありません。
Tim Sexton 2016年

3

IISを再起動します-デバッガに接続されたプロセスである可能性があります


3

ウイルス対策を無効にしてお試しください。 私もその問題に直面していました...しかし私の場合、ウイルス対策を無効にすると、ウイルス対策がアプリケーションをブロックしていました。


3

私は同じエラーに直面しました。

ビンの内容をすべて削除して問題を解決しましたすべての依存プロジェクト/ライブラリフォルダーの。

このエラーは主にバージョンの変更が原因で発生します。



1

最初に簡単なことを行います。

ソリューションの一部が実行中のプロセスによってロックされていないことを確認してください。

たとえば、Windowsサービスで「InstallUtil」を実行しました(通常、コンソールから単体テストを実行しています)。

これにより、Windowsサービスプロジェクトのbinフォルダーにあるいくつかのdllがロックされました。再構築を行ったときに、この問題で例外が発生しました。

Windowsサービスを停止して再構築し、成功しました。

この問題の事前手順を実行する前に、Windowsタスクマネージャでアプリケーションを確認してください。

だから足音を聞くときは、シマウマではなく馬だと思ってください!(医学生友達から)


1

同じ問題がありました。bin \ debugからobj .....にコピーできませんでした。

Webプロジェクトをビルドしたとき、dllがすべてbin \ debugではなくbinフォルダーにあることがわかりました。公開中、vsはbin \ debugでファイルを探していました。だから私はエディターでwebプロジェクトファイルを開いてbin \ debugのインスタンスを探し、すべてのdllがbin \ debug \ mylibrary.dllとして言及されていることを発見しました。パスからすべての\ debugを削除して、再度公開しました。今回vsはbinフォルダー内のすべてのdllを見つけることができ、公開に成功しました。

このパスがWebプロジェクトファイルでどのように変更されたかはわかりません。

これをデバッグするのに5時間以上費やし、ようやく自分で解決策を見つけました。

これが正解です。


1

上記のいずれも機能せず、コンソールアプリケーションを開発している場合:

Program.csに文字を入力してから、削除してください。なぜこれが機能するのかはわかりませんが、「コピーできません」という問題は毎回解決されるようです。


1

これはかなり一般的にアバストが原因です。

私は通常、リリースに関係なく自分のプロジェクトを実行できますが、デバッグで実行すると、かなり定期的に失敗します。

プロジェクトフォルダーの除外を追加するだけで、問題は解消したようです。これは他のウイルス対策ソフトウェアが原因である可能性もあります。


1

.exeおよび.pubファイルの名前を変更することは私にとってはうまくいきましたが、本当に面倒です。また、デバッグセッション中に編集できないという問題にも直面しています。最後に、次のように詳細セキュリティ設定ページに行きました。

https://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k%28%22VS.ERR.DEBUG_IN_ZONE_NO_HOSTPROC%3a11310%22%29;k%28TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION %3dV4.0%22%29&rd = true

[ClickOnceセキュリティ設定を有効にする]チェックボックスをオフにしてから、もう一度オンにします。何日か問題はありませんでした...


1

私にとってこれは、ターゲットフォルダーでコマンドプロンプトを開いていることが原因でした(C:\users\username\source\repos\project\project\bin\debug\app.publish)でした。

デバッグに発行フォルダへのアクセスが必要な理由はわかりませんが、コマンドウィンドウを閉じると問題が解決しました。


1

ユニットテストのデバッグまたはユニットテストの実行中に誰かがこれに遭遇した場合、ファイルを解放するために次の2つのプロセスを強制終了する必要がありました。

強制終了するプロセス。


0

あなたが提供したいくつかの解決策を試しましたが、時々私はまだこのエラーを受け取ります。プロセスが実行されていないことを確信しています。InternetExplorerで実行可能ファイルを削除しようとすると、ファイルリストから削除されますが、F5キーを押すと、ファイルが元に戻ります。全く削除されていません。

しかし、TotalCommanderを使用してファイルを削除すると、exeファイルは実際に削除され、プロジェクトを正常にビルドできます。

私はWindows 7 x64とトータルコマンダー7.56a 32ビットを使用しています。


0

他の答えはどれもうまくいきませんでしたが、Visual Studioで開いているすべてのタブを閉じると問題が解決したようです。


0

これは非常に古い質問であることはわかっていますが、最近、VS 2012で「objからbinにコピーできません」というエラーが発生しました。特定のプロジェクトを再構築しようとするたびに、メッセージが表示されました。唯一の解決策は、すべての再構築の前にクリーンアップを行うことでした。

多くの調査の結果、コンパイルの成功を妨げなかった私のファイルの1つに不完全なプラグマ警告ステートメントがあったことがわかりましたが、VSをファイルをロックしておくことに混乱させていました。

私の場合、ファイルの先頭に次のものがありました。

#pragma warning(

それでおしまい。私はしばらく前に何かをしようとしていて、気が散ってプロセスを終えることはなかったと思いますが、その特定のラインに関するVS警告はシャッフルで失われました。結局、私は警告に気づき、行を削除し、それ以来毎回リビルドが機能しました。


0

私が同様の問題に直面したとき、機能しているように思われた唯一のものは:

  • プロジェクトを右クリックして[設定]に移動し、デバッグビルドとリリースビルドの両方が同じ設定をターゲットにしていることを確認するか、アプリケーションがロードまたは保存しようとしている設定をそこに含めます。
  • C:\ Users(YourUserAccount)\ AppData \ Local(YourAppName)フォルダーを削除します。
  • そこにあるファイルが「ブロックされている」と見なされていないことを確認します。プロジェクトに含まれているファイルを右クリックすると、1つのアイコンが実際にブロックされており、インターネットからダウンロードされたために悪いと考えられていることに気付きました。[ブロックを解除]ボタンをクリックする必要がありました(たとえば、こちらを確認してください:http : //devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png- "このファイルは別のコンピューターからのものであり、ブロックされている可能性がありますこのコンピュータを保護してください。」)。

0

WCFを使用するWindowsサービスの場合、WFCホストプロセスを終了しましたが、動作しました。これが起こるとき、私はそれを嫌います、そしてそれは時々ランダムに起こります。


0

私のソリューションは、バージョン、プロセスのロック、再起動、またはファイルの削除とは何の関係もありません。

問題は実際にはビルドの失敗によるものであり、正しいエラーを提供していません。実際の問題は設計上の欠陥でした:

// Either this should be declared outside the function, or..
SomeObject a = new SomeObject(); 

Task.Factory.StartNew(() =>
{
   while (true)
   {
      a.waitForSomething();
   }
});

// ...this should not be called
a.doSomething(); 

「a」のスコープを関数の外に変更した後、または「a」を使用しなかった後 Task.Factory.StartNew();、再構築することができました。

これは、Windows7x64 sp1でVS2012 Update 4を使用しているときに発生しました。

エラーメッセージ:

C:\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets(3390,5):エラーMSB3030:ファイル "obj \ x86 \ Debug \ xxx.exe"が見つからなかったため、コピーできませんでした。


0

VS2013でこのエラーが定期的に発生することがわかりました。ある程度うまく機能しているように見えるのは、アプリケーションを実行する前に再構築ソリューションを実行することです。CLEANを実行するとうまくいく場合があることがわかりましたが、Rebuild Solutionはより一貫して機能しているようです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.