Visual Studio 構建失敗：無法將 exe 文件從 obj\debug 復制到 bin\debug

Question

更新：可以在 Microsoft Connect中找到重現此錯誤的示例項目。 我還測試並驗證了下面接受的答案中給出的解決方案適用於該示例項目。 如果此解決方案對您不起作用，則您可能遇到了不同的問題（屬於單獨的問題）。

---

這是以前在 Stack Overflow 和其他地方提出的問題，但到目前為止我發現的任何建議都沒有幫助我，所以我只需要嘗試提出一個新問題。

場景：我有一個簡單的 Windows 窗體應用程序（C#、.NET 4.0、Visual Studio 2010）。 它有幾個大多數其他表單繼承自的基本表單，它使用實體框架（和 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中的一個錯誤，如果是，有補丁嗎？ 或者我做錯了什么，我有循環引用或類似的，如果有，我怎么能找到？

任何建議都非常感謝:)

更新：正如下面評論中提到的，我還使用 Process Explorer 檢查了它實際上是鎖定文件的 Visual Studio。

Answer 1

這聽起來很愚蠢，但我嘗試了所有這些解決方案，在 Windows 7 上運行 VS2010。除了重命名和構建之外，它們都不起作用，這至少可以說非常乏味。 最終，我找到了罪魁禍首，我覺得難以置信。 但是我在 AssemblyInfo.cs 中使用了以下代碼...

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

這很常見，但出於某種原因，將版本更改為 2.0.0.0 使事情再次運行。 我不知道它是否是 Windows 7 特定的東西（我只使用了 3-4 周），或者它是隨機的，還是什么，但它為我修復了它。 我猜 VS 在它生成的每個文件上都有一個句柄，所以它會知道如何增加東西？ 我真的不確定，以前從未見過這種情況。 但是，如果外面的其他人也在拔頭發，請嘗試一下。

Answer 2

我找到了一個簡單的解決方案，只需禁用項目文件夾和子文件夾的 Windows 索引服務

Answer 3

由於我沒有收到關於這個問題的更多反饋，我想我只是分享一下我的解決方案：

正如 Barry 在對原始帖子的評論中所建議的那樣，手動將'...bin\\Debug[ProjectName].exe'重命名為其他名稱（例如'[ProjectName]1.exe' ）是一種解決方法（I'但是不允許我自己刪除文件，我必須說我發現這有點奇怪，因為人們認為防止刪除的相同鎖也會防止重命名......）。 這不是一個好的解決方案，但它的速度相當快（至少在你做了幾次之后，它幾乎變成了一個例行程序），並且至少比重新啟動 Visual Studio 快得多，這是我在開始時所做的。

如果有人想知道，我還可以補充一點，我只是半隨機地看到這個問題。 它通常發生在我對表單的設計模式進行了一些更改之后（但並非總是如此）。 如果我只更改業務邏輯代碼或非視覺相關代碼，通常不會發生這種情況（但有時會發生......）。 確實令人沮喪，但至少我有一個對我有用的黑客 - 讓我們只希望我的下一個項目也不會面臨這個問題......

@Barry：如果您想獲得評論的贊譽，請隨時將其發布為答案，我會確保接受它:)

Answer 4

我在 VS2008 中的 WPF 項目（在 Windows 7 x32 上）有同樣的問題（MSB3021）。 如果我嘗試在上次運行后過快地重新運行應用程序，就會出現問題。 幾分鍾后，exe 文件自行解鎖，我可以再次重新運行應用程序。 但是這么長的停頓讓我很生氣。 唯一真正幫助我的是以管理員身份運行 VS。

Answer 5

當我遇到這個問題時，這是因為我嘗試構建的項目被設置為解決方案中的啟動項目，從而使 obj 文件夾中的 .exe 被鎖定（它也出現在您的任務管理器中，）右鍵單擊解決方案中的另一個項目，然后選擇設置啟動項目。 這將釋放鎖定，將其從任務管理器中刪除，並且應該讓您構建。

Answer 6

我在這里的答案中嘗試了所有其他建議，但都沒有奏效。 最終我使用 Process Monitor 發現我的 VS2010 無法構建的 .exe 被系統進程（PID = 4）鎖定。 在涉及此的情況下搜索 SO 產生了這個答案。

總結：如果您禁用了應用程序體驗服務（就像我一樣），請重新啟用並啟動它。 兩年的惡化結束了。

Answer 7

我也有一個與此非常相似的問題，在我的案例中，我發現 bin\\debug 文件夾作為 VMware 下的共享文件夾可用，VM 來賓下的 VMware、Explorer 或什至可能是防病毒軟件來賓下的程序（盡管我認為我沒有安裝）正在持有文件的句柄。

Answer 8

禁用“啟用 Visual Studio 托管進程”

Answer 9

如果您的問題尚未解決：

Visual Studio 的錯誤是：

“該進程無法訪問文件 'bin\\Debug**app.exe**'，因為它正被另一個進程使用。”

因此，轉到windows的任務管理器（Ctrl+Shift+Esc），找到您的應用程序名稱並通過Endprocces強制關閉它。

Answer 10

我建議下載Process Explorer以准確找出鎖定文件的進程。 它可以在以下位置找到：

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

Answer 11

使用 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

Answer 12

這是另一種可能性：

在vs2012/win7中收到此錯誤后，我去嘗試刪除bin目錄中的文件，資源管理器顯示該文件正在被XAML UI Designer使用。

我關閉了我在 VS 中打開的所有選項卡，關閉了 VS，然后確保在任務管理器中殺死所有 MSBuild 進程。 最后，在重新啟動 VS 后，我能夠構建解決方案。

---

另一個可能的原因：

我注意到此問題的另一個可能原因。 在進行了一些代碼重構、將項目移入和移出解決方案后，我的項目引用不再按預期引用解決方案中的項目。

這誤導了 Visual Studio 認為它可以同時構建一些項目，從而創建文件鎖。

編輯：我最近在 VS2012 上也發生過這種情況，一旦我將構建順序設置為正確的依賴項，它就會修復它，殺死 VS 繼續運行的所有 msbuild 進程，然后重新啟動 VS。 我只是為了確定而終止了 msbuild 進程，但關閉 VS 也應該終止它們。

我通常做的事情是重構一個項目，使其依賴於解決方案中的另一個項目，它在上次構建時沒有引用。 這有時似乎會使 VS 感到困惑，並且它不會更新構建順序。

要檢查構建順序：在解決方案資源管理器中右鍵單擊解決方案，然后選擇“項目構建順序...”並驗證是否正確記錄了每個項目的依賴關系。

Answer 13

重新啟動 IIS- 可能是附加到調試器的進程

Answer 14

禁用防病毒軟件並嘗試。 我也遇到了這個問題......但在我的情況下，當我禁用防病毒軟件時，防病毒軟件阻止了我的應用程序。

Answer 15

我遇到了同樣的錯誤。

我通過刪除所有依賴項目/庫的bin文件夾的所有內容解決了這個問題。

此錯誤主要由於版本更改而發生。

Answer 16

這已在 Microsoft 的社區錯誤報告站點 Connect 上多次提交。 僅供參考，我相信這個錯誤自 2003 年以來一直困擾着 Visual Studio，並且每次都在 RTM 之后得到修復。 :( 參考資料之一如下：

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

Answer 17

先做簡單的事情。

檢查您的解決方案的一部分沒有被正在運行的進程鎖定。

例如，我在我的 Windows 服務（我通常從控制台進行單元測試）上運行了“InstallUtil”。

這將我的一些 dll 鎖定在 windows 服務項目的 bin 文件夾中。 當我進行重建時，我在這個問題中遇到了異常。

我停止了 Windows 服務，重建並成功了。

在執行此問題中的任何高級步驟之前，請檢查您的應用程序的 Windows 任務管理器。

所以當你聽到腳步聲時，想想馬而不是斑馬！ （來自醫學生朋友）

Answer 18

我有同樣的問題。 它說無法從 bin\\debug 復制到 obj .....

當我構建 web 項目時，我發現我的 dll 都在 bin 文件夾中，而不是在 bin\\debug 中。 在發布期間，vs 正在尋找 bin\\debug 中的文件。 所以我在編輯器中打開 web 項目文件並查找 bin\\debug 的實例，我發現所有的 dll 都被稱為 bin\\debug\\mylibrary.dll。 我從路徑中刪除了所有 \\debug 並再次發布。 這次vs能夠在bin文件夾中找到所有dll並發布成功。

我不知道這個路徑是如何在 web 項目文件中改變的。

我花了5個多小時調試這個，最后自己找到了解決方案。

這是正確的答案。

Answer 19

如果以上都不起作用，並且您正在開發控制台應用程序：

嘗試在 Program.cs 中輸入任何字符，然后將其刪除。 我不知道為什么會這樣，但似乎每次都能解決“無法復制”的問題。

Answer 20

這通常是由 Avast 引起的。

無論如何，我通常可以在 Release 中運行我的項目，但是在調試中運行時，它經常會失敗。

我只是為我的項目文件夾添加了一個排除項，問題似乎消失了。 我認為這也可能是由其他防病毒軟件引起的。

Answer 21

重命名 .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.NETVERSIONWORK %3dV4.0%22%29&rd=true

我取消選擇然后重新選擇“啟用 ClickOnce 安全設置”復選框。 好幾天沒出問題了....

Answer 22

對我來說，這是由於在目標文件夾（ C:\\users\\username\\source\\repos\\project\\project\\bin\\debug\\app.publish ）中打開命令提示符引起的。

不確定為什么調試需要訪問發布文件夾，但關閉命令窗口為我解決了這個問題。

Answer 23

如果有人在嘗試調試單元測試或運行單元測試時遇到此問題，我必須終止以下兩個進程才能釋放文件：

Answer 24

其他答案都不適合我，但關閉 Visual Studio 中所有打開的選項卡似乎已經解決了問題。

Answer 25

我知道這是一個非常古老的問題，但我最近在 VS 2012 中遇到了“無法從 obj 復制到 bin”錯誤。每次我嘗試重建某個項目時，我都會收到消息。 唯一的解決方案是在每次重建之前進行清理。

經過大量調查，結果發現我的一個文件中有一個不完整的 pragma 警告聲明，該聲明並未阻止編譯成功，但不知何故使 VS 混淆以保持文件鎖定。

就我而言，我在文件頂部有以下內容：

#pragma warning(

就是這樣。 我想我前一段時間試圖做某事並且分心並且從未完成該過程，但是關於該特定行的 VS 警告在洗牌中丟失了。 最終我注意到了警告，刪除了這條線，從那以后每次都重建工作。

Answer 26

當我遇到類似的問題時，似乎唯一有效的方法是：

• 右鍵單擊項目，轉到設置，並確保調試和發布構建針對相同的設置，或者在其中包含應用程序嘗試加載或保存的設置。
• 刪除 C:\\Users(YourUserAccount)\\AppData\\Local(YourAppName) 文件夾。
• 確保我在那里的任何文件都沒有被視為“已阻止”。 右鍵單擊我的項目包含的文件，我意識到一個圖標實際上被阻止並被認為是壞的，因為它是從互聯網上下載的。 我必須單擊取消阻止按鈕（例如，請查看： http : //devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png -“此文件來自另一台計算機，可能會被阻止以提供幫助保護這台計算機。”）。

Answer 27

對於使用 WCF 的 Windows 服務，我結束了 WFC 主機進程並且它起作用了。 當這種情況發生時，我討厭它，它有時會隨機發生。

Answer 28

我的解決方案與版本、進程被鎖定、重新啟動或刪除文件無關。

問題實際上是由於構建失敗，並且沒有給出正確的錯誤。 實際問題是設計缺陷：

// 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” Task.Factory.StartNew(); ，我能夠再次構建。

在 Windows7x64 sp1 上使用 VS2012 Update 4 時會發生這種情況。

錯誤信息：

C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\Microsoft.Common.targets(3390,5): error MSB3030: 無法復制文件“obj\\x86\\Debug\\xxx.exe”，因為找不到.

Answer 29

我發現在 VS2013 中我經常收到這個錯誤。 在嘗試運行應用程序之前執行重建解決方案似乎工作得相當好。 我發現執行 CLEAN 有時有效，但重建解決方案似乎更一致地工作。

Answer 30

在我從 bin 目錄中刪除只讀標志后，這對我有幫助。 http://www.thewindowsclub.com/error-0x80080015-windows-defender-activation-requires-display-name

Answer 31

1. 將另一個項目設置為啟動
2. 構建項目（將顯示沒有問題的項目）
3. 轉到有問題的bin\debug文件夾
4. 將myservice.vshost.exe重命名為myservice.exe

Answer 32

真正幫助我的一件事是將調試文件夾中的“.exe”添加到我的防病毒軟件的排除項中。

Answer 33

[已解決] 無法將 exe 文件從 obj\debug 復制到 bin\debug：

我正在接近您在嘗試一個接一個地運行兩個窗口時遇到此錯誤，例如首先加載一個表單，然后有時它會自動消失並將第二個表單加載到屏幕上。

基本上，您需要關閉在后台運行的第一個表單以及此錯誤背后的主要原因。

要關閉第一個表單，您必須在第二個表單加載事件處理程序中添加這兩行代碼。

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

這將完美地解決錯誤。

Answer 34

重新啟用 Windows 的應用程序體驗服務為我解決了此類問題。

請參閱以下鏈接：

• Visual Studio 輸出文件權限？
• 系統進程（PID 4）在什么情況下會保留打開的文件句柄？

我在使用 Windows 7 64 位的 Visual Studio 2008、2010 和 2013 時遇到了問題。

Answer 35

我多次遇到同樣的問題，但兩種不同的方法結合起來有幫助。 在所有情況下，有一個事實很有趣，即您仍然可以重命名文件。 如果文件被進程打開，則無法重命名它。 所以它一定不是簡單的打開文件句柄。

1. 在編譯生成 IL 代碼的解決方案時，即使它只包含一些命令，Defender 也會完全阻止它。 即使將該目錄添加到 Windows Defender 的排除列表中也無濟於事。 我認為 Windows Defender 的病毒掃描存在缺陷，如果文件具有某種未完成狀態並阻止文件，則會進入無限循環（或故障？）。 但它永遠不會恢復，除非在 PC 重新啟動后。
2. 由於調試器停止按鈕不起作用，或者在使用停止按鈕進行常規停止時，我不得不在調試時終止我的解決方案后，我遇到了無法訪問的錯誤，我不記得了。 一些 dll 似乎保持鎖定狀態，無法刪除，但我可以重命名它們 (??)。 然后我使用“tasklist.exe”列出所有進程，令我驚訝的是，還有一個進程仍然以我的應用程序名稱列出。 無窗。 並且任務管理器沒有在“詳細信息”中列出它。 奇怪的。 我可以使用 taskkill /PID:... /F （ /F 是必要的）並且該過程進行了。 之后編譯成功，一切恢復正常。 看起來這個 exe 持有 DLL，但方式很奇怪。

當 Oracle VirtualBox 也在運行時，它也會發生更多。 不知道有沒有影響。 也可能與 VirtualBox 消耗大量內存時有時報告的“內存不足”異常有關。

現在，每當出現問題時，我都會結合使用這兩種方法。 它仍然不時發生。

Answer 36

我嘗試了您提供的幾種解決方案，但有時我仍然收到此錯誤。 我確定我的進程沒有運行，當我嘗試使用 Internet Explorer 刪除可執行文件時，它會從文件列表中刪除，但隨后我按 F5，瞧，文件又回來了。 它根本沒有被刪除。

但是如果我通過 TotalCommander 刪除文件，實際上是刪除了 exe 文件，我可以成功構建項目。

我正在使用 windows 7 x64 和 totalcommander 7.56a 32 位。