web-dev-qa-db-ja.com

Visual Studioビルドが失敗します：exeファイルをobj \ debugからbin \ debugにコピーできません

更新：このバグを再現するサンプルプロジェクトが見つかりました- ここMicrosoft Connect 。また、 以下の受け入れられた回答 で示されたソリューションがそのサンプルプロジェクトで機能することをテストおよび検証しました。この解決策がうまくいかない場合は、おそらく別の問題があります（別の質問に属します）。

これは、Stack Overflowと他の場所の両方で以前に尋ねられた質問ですが、ここまで見つけた提案はどれも役に立たなかったので、新しい質問をするだけです。

シナリオ：単純なWindowsフォームアプリケーション（C＃、. NET 4.0、Visual Studio 2010）があります。他のほとんどのフォームが継承する基本フォームがいくつかあり、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の実行時に警告とエラーの両方が表示されますが、実行中のエラーのみビルド-それは関係ないと思いますか？）

警告とエラーメッセージの内容は完全に理解できます。VisualStudioは明らかに、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のバグですか？バグがある場合、パッチはありますか？または、何か間違ったことをしましたか、循環参照などを持っていますか？

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

更新：以下のコメントで述べたように、Process Explorerを使用して、実際にisであることも確認しましたファイルをロックしているVisual Studio。

c#.netwinformsvisual-studio
189
Julian

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

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

これはかなり一般的ですが、何らかの理由で、バージョンを2.0.0.0に変更すると再び機能するようになりました。 Windows 7固有のもの（3〜4週間しか使っていません）なのか、ランダムなのか、何なのかはわかりませんが、修正されました。私はVSが生成した各ファイルのハンドルを保持していると推測しているので、物事をインクリメントする方法を知っているでしょうか？私は本当に確信がありません、そして、これが前に起こるのを見たことがありません。しかし、他の誰かが髪の毛を抜いている場合は、試してみてください。

115
drharris

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

14
Pedro

私はこの問題についてこれ以上フィードバックを受け取っていないため、最終的に解決策になったものを共有したいと思いました。

元の投稿へのコメントでバリーが示唆したように、手動で'... bin\Debug [ProjectName] .exe'を別の名前に変更します（例'[ProjectName] 1。 exe '）は回避策の1つです（ただし、自分でファイルを削除することは許可されていませんが、削除を防止する同じロックが名前の変更を防ぐと信じているため、少し奇妙だと思う必要があります... ）。それは良い解決策ではありませんが、合理的な高速（少なくとも2、3回実行した後は、ほとんどルーチンになります）であり、少なくとも最初に行ったVisual Studioの再起動よりもはるかに高速です。

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

@Barry：コメントのクレジットを取得したい場合は、回答として自由に投稿してください。私はそれを必ず受け入れます:)

14
Julian

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

12
Sergey

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

9
Adrian Booth

ここでの回答にある他のすべての提案を試しましたが、どれもうまくいきませんでした。最終的に、VS2010がビルドに失敗した.exeがシステムプロセス（PID = 4）によってロックされていることを発見するために、プロセスモニターを使用しました。これに関連する状況についてSOを検索すると、 this answerが得られました。

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

8
Eight-Bit Guru

また、これと非常によく似た問題があり、私のケースの理由は、bin\debugフォルダーをVMwareおよびVMゲストの下のVMware、Explorerのいずれかで共有フォルダーとして使用できるようにしたことです。おそらくゲストの下のアンチウイルスプログラム（インストールされているとは思いませんが）でもファイルへのハンドルを保持していました。

6
Quinxy von Besiex

「Visual Studioホスティングプロセスを有効にする」を無効にします Project Debug Settings

5
BCS Software

問題がある場合ISまだ解決されていません：

Visual Studioのエラー：

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

Windowsのタスクマネージャー（Ctrl + Shift + Esc）に移動し、アプリケーション名を見つけてEndproccesで強制終了します。

4
AmirHossein Rezaei

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

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

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

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
3
danielm

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

すべての依存プロジェクト/ライブラリのbinフォルダーのすべてのコンテンツを削除することで問題を解決しました。

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

3
Utsav Dawn

ウイルス対策を無効にして試してください。私もその問題に直面していました...しかし、私の場合、ウイルス対策は、ウイルス対策を無効にすると解決しました。

3
Hassan_Jaffrani

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

3
Alan

別の可能性があります：

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

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

および別の考えられる原因：

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

これにより、Visual Studioがいくつかのプロジェクトを同時にビルドし、ファイルロックを作成する可能性があると誤解します。

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

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

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

3
Kevin Shanahan

これは、Microsoftのコミュニティバグ報告サイトであるConnectで複数回報告されています。参考までに、このバグは2003年以降Visual Studioに影響を与えており、毎回RTM後に修正されていると思います。 :(参照の1つは次のとおりです。

https://connect.Microsoft.com/VisualStudio/feedback/details/568672/handles-to-project-dlls-are-not-released-when-compiling?wa=wsignin1.

2
Michael

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

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

2
Hans Olsson

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

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

私は自分のプロジェクトフォルダに除外を追加するだけで、問題はなくなるようです。これは他のウイルス対策ソフトウェアの原因でもあると思います。

1
James Pusateri

私にとって、これはターゲットフォルダー（C:\users\username\source\repos\project\project\bin\debug\app.publish）でコマンドプロンプトを開くことで発生していました。

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

1
Bassie

.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
Yee

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

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

1
Greg

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

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

本当に助けになったのは、Debugフォルダの ".exe"をAnti-Virusの除外に追加したことです。

0
Ricardo Ferreira

他の答えは私には役に立たなかったが、Visual Studioで開いているすべてのタブを閉じることで問題は解決したようだ。

0
Ian Mercer

あなたが提供したいくつかの解決策を試しましたが、時々このエラーが表示されることがあります。私は自分のプロセスが実行されていないことを確信しており、Internet Explorerで実行可能ファイルを削除しようとすると、ファイルリストから削除されますが、F5キーを押すとファイルが戻ります。まったく削除されていません。

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

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

0
Gico

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

0
ShaunnyBwoy

最初に簡単なことをしてください。

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

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

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

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

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

足音が聞こえたら、馬はシマウマではないと思います！ （医学生の友人から）

0
GregJF

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

processes to kill.

0
Haggis777

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

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

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

#pragma warning(

それでおしまい。私はしばらく前に何かをしようとして、気を取られてプロセスを完了しなかったと思いますが、その特定の行に関するVSの警告はシャッフルで失われました。最終的に私は警告に気づき、ラインを削除し、それ以降毎回再構築が機能します。

0
Chris

同じ問題がありました。 bin\debugからobj .....にコピーできなかったと言いました。

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

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

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

これは正解です。

0
nccsbim071

[解決済み] exeファイルをobj\debugからbin\debugにコピーできません：

最初にフォームをロードし、その後自動的に消えて、2番目のフォームが画面にロードされるなど、2つのウィンドウフォームを次々に実行しようとすると、このエラーが発生することに近づいています。

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

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

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

これにより、エラーが完全に解決されます。

0
Sabir Al Fateh

Windowsの Application Experience サービスを再度有効にすると、この種の問題が修正されました。

次のリンクを参照してください。

Windows 7 64ビットでVisual Studio 2008、2010、2013を使用すると問題が発生しました。

0
Wollmich

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

0
mattpm

これは、binディレクトリから読み取り専用フラグを削除した後に役立ちます。 http://www.thewindowsclub.com/error-0x80080015-windows-defender-activation-requires-display-name

0
Suhan
  1. 別のプロジェクトをスタートアップとして設定する
  2. プロジェクトをビルドします（問題のないプロジェクトが表示されます）
  3. 問題のあるbin\debugフォルダーに移動します
  4. myservice.vshost.exeの名前をmyservice.exeに変更します
0
Peter PitLock

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

この問題は、実際にはビルドの失敗が原因であり、正しいエラーを表示していませんでした。実際の問題は設計上の欠陥でした：

// 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」のスコープを関数の外側に変更した後、またはTask.Factory.StartNew();の後に「a」を使用しなかった後、再度ビルドできました。

これは、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
T.Coutlakis