Visual Studio构建失败：无法将exe文件从obj \ debug复制到bin \ debug

时间：2010-05-24 09:18:10

标签： c# .net winforms visual-studio

更新： 可以找到重现此错误的示例项目here at Microsoft Connect。我还测试并验证了the accepted answer below中给出的解决方案适用于该示例项目。如果此解决方案不适合您，您可能遇到了另一个问题（属于单独的问题）。

这是一个之前提出的问题，这里都是关于Stack Overflow和其他地方的问题，但是我发现的这些建议都没有帮助我，所以我只想尝试一个新问题。

场景：我有一个简单的Windows窗体应用程序（C＃，.NET 4.0，Visual Studio 2010）。它有大多数其他形式继承的基本形式，它使用Entity Framework（和POCO类）进行数据库访问。没什么好看的，没有多线程或任何东西。

问题：一段时间都很好。然后，当我即将启动应用程序时，Visual Studio无法构建。我收到警告“无法删除文件'... bin \ Debug \ [ProjectName] .exe'。访问路径'... bin \ Debug \ [ProjectName] .exe'被拒绝。”< / em>和错误“无法将文件'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。

35 个答案:

答案 0 :(得分：114)

这听起来很愚蠢，但我尝试了所有这些解决方案，在Windows 7上运行VS2010。除了重命名和构建之外，它们都没有工作，至少可以说这非常繁琐。最终，我找到了罪魁祸首，我发现很难相信。但是我在AssemblyInfo.cs中使用了以下代码...... 

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

这很常见，但出于某种原因，将版本更改为2.0.0.0会使事情再次发挥作用。我不知道它是否是Windows 7特定的东西（我只使用它3-4周），或者它是随机的，或者是什么，但它为我修复了它。我猜测VS正在处理它生成的每个文件，所以它会知道如何增加内容​​吗？我真的不确定，从来没有见过这种情况。但如果那里的其他人也把头发拉了出来，试一试。

答案 1 :(得分：14)

由于我还没有得到关于这个问题的任何反馈，我想我只是分享最终成为我的解决方案：

正如Barry在对原帖的评论中所建议的那样，手动将'... bin \ Debug [ProjectName] .exe'重命名为其他内容（例如'[ProjectName] 1.exe'）是一种解决方法（但我不允许自己删除文件，我必须说我觉得有点奇怪，因为人们会相信防止删除的同一个锁也会阻止重命名...）。这不是一个好的解决方案，但是它的合理性很快（至少在你完成它几次之后，它几乎成了例程），并且至少比重启Visual Studio更快，这是我在开始时所做的。 / p>

如果有人想知道，我还可以补充一点，我只是半随机地看到这个问题。它通常发生在我对表单的设计模式进行了一些更改之后（但并非总是如此）。如果我只改变业务逻辑代码或非视觉相关代码（但有时它会......），通常不会发生这种情况。确实令人沮丧，但至少我有一个适合我的黑客 - 让我们只希望我的下一个项目也不会面临这个问题......

@Barry：如果您希望获得评论，请随时将其作为答案发布，我一定会接受它：）

答案 2 :(得分：14)

我找到了一个简单的解决方案，只需为项目文件夹和子文件夹禁用Windows索引服务

答案 3 :(得分：12)

我在VS2008中使用WPF项目时遇到了同样的问题（MSB3021）（在Windows 7 x32上）。 如果我尝试在上次运行后重新运行应用程序太快，则会出现此问题。 几分钟后，exe文件自行解锁，我可以重新运行应用程序。但这么长的停顿让我感到愤怒。 唯一真正帮助我的是以管理员身份运行VS.

答案 4 :(得分：9)

当我遇到这个问题时，我将尝试构建的项目设置为解决方案中的启动项目，使得obj文件夹中的.exe被锁定（它也出现在您的任务中）经理，）右键单击解决方案中的另一个项目，然后选择设置启动项目。这将释放锁，将其从任务管理器中删除，并让你建立。

答案 5 :(得分：8)

我在这里的答案中尝试了所有其他建议，但都没有奏效。最后，我使用Process Monitor发现VS2010无法构建的.exe被系统进程锁定（PID = 4）。搜索SO以查找涉及此问题的情况会产生this答案。

总结：如果禁用了Application Experience服务（就像我一样），那么重新启用并启动它。两年的恶化已经结束。

答案 6 :(得分：6)

我也有一个与此非常相似的问题，并且发现我的理由是我将bin \ debug文件夹作为VMware下的共享文件夹以及VMware客户端下的VMware，Explorer，或者甚至是客人下的反病毒程序（虽然我认为我没有安装过）但是手持文件的句柄。

答案 7 :(得分：5)

禁用＆＃34;启用Visual Studio托管流程＆＃34; Project Debug Settings

答案 8 :(得分：4)

如果你的问题没有得到解决：

Visual Studio的错误是：

“进程无法访问文件'bin \ Debug ** app.exe **'，因为它正由另一个进程使用。”

因此，转到Windows的任务管理器（Ctrl + Shift + Esc），找到您的应用程序名称  并强制它由Endprocces关闭。

答案 9 :(得分：3)

重新启动IIS-可能是附加到调试器的进程

答案 10 :(得分：3)

我遇到了同样的错误。

我通过删除所有相关项目/库的 bin 文件夹的所有内容来解决问题。

此错误主要是由于版本更改造成的。

答案 11 :(得分：3)

禁用防病毒并尝试。 我也遇到了这个问题...但在我的情况下，当我禁用防病毒时，防病毒软件阻止了我的应用程序。

答案 12 :(得分：3)

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

答案 13 :(得分：3)

这是另一种可能性：

在vs2012 / win7中收到此错误后，我去尝试删除bin目录中的文件，并且资源管理器指示该文件已由XAML UI Designer使用。

我关闭了我在VS中打开的所有选项卡，关闭了VS，然后确保杀死taskmanager中的所有MSBuild进程。最后，重新启动VS后，我能够构建解决方案。

和另一个可能的原因：

我注意到了这个问题的另一个可能原因。在进行一些代码重构，将项目移入和移出解决方案后，我的项目引用不再按预期引用解决方案中的项目。

这个误导的视觉工作室认为它可以同时构建一些项目，从而创建文件锁。

编辑：我甚至在最近使用VS2012的情况下发生了这种情况，并且一旦我将构建顺序设置为正确的依赖关系，它就会修复它，杀死VS运行的任何msbuild进程，然后重新启动VS.我确实杀了msbuild进程，但关闭VS也应该杀死它们。

我通常做的是重构一个项目，使它依赖于解决方案中的另一个项目，它在上一次构建时没有引用。这有时似乎让VS感到困惑，并且它不会更新构建顺序。

要检查构建顺序：在解决方案资源管理器中右键单击解决方案，然后选择“项目构建顺序...”并验证是否为每个项目正确记录了依赖项。

答案 14 :(得分：2)

这已在Connect，Microsoft的社区错误报告网站上多次提交。仅供参考，我相信这个bug自2003年以来一直困扰着Visual Studio，并且每次都在RTM之后修复。 :(其中一个参考文献如下：

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

答案 15 :(得分：2)

我建议下载Process Explorer以确切了解锁定文件的进程。它可以在：

找到

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

答案 16 :(得分：1)

对我而言，这是因为在目标文件夹（C:\users\username\source\repos\project\project\bin\debug\app.publish）中打开了命令提示符。

不确定为什么DEBUGGING需要访问发布文件夹，但关闭命令窗口可以解决我的问题。

答案 17 :(得分：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

我取消选择然后重新选择＆＃34;启用ClickOnce安全设置＆＃34;复选框。它已经有几天没有问题......

答案 18 :(得分：1)

如果以上都不起作用，并且您正在开发控制台应用程序：

尝试在Program.cs中键入任何字符，然后将其删除。我不知道为什么会这样，但似乎每次都会解决“无法复制”问题。

答案 19 :(得分：1)

这通常是由Avast引起的。

我通常可以在Release中运行我的项目，但是在调试中运行它会经常失败。

我只是为我的项目文件夹添加一个排除项，问题似乎消失了。我认为这也可能是其他防病毒软件引起的。

答案 20 :(得分：0)

如果有人在尝试调试单元测试或运行单元测试时遇到此问题，我必须终止以下两个进程才能释放文件：

processes to kill.

答案 21 :(得分：0)

[已解决]无法将exe文件从obj \ debug复制到bin \ debug：

我正在接近你在尝试一个接一个地运行两个窗口时遇到这个错误，比如先加载一个表单，然后有时它会自动消失，第二个表单加载到屏幕上。

基本上，您需要关闭在后台运行的第一个表单以及此错误背后的主要原因。

要关闭第一个表单，您必须在第二个表单加载事件处理程序中添加这两行代码。

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

这将完美地解决错误。

答案 22 :(得分：0)

真正帮助我的一件事是将Debug文件夹中的“.exe”添加到我的Anti-Virus上的Exclusions。

答案 23 :(得分：0)

重新启用Windows的Application Experience服务已经为我解决了这类问题。

请参阅以下链接：

我使用Visual Studio 2008,2010和2013使用Windows 7 64位时遇到了问题。

答案 24 :(得分：0)

  1. 将另一个项目设置为启动
  2. 构建项目（将显示无问题的项目）
  3. 转到有问题的bin\debug文件夹
  4. 将myservice.vshost.exe重命名为myservice.exe

答案 25 :(得分：0)

在我从bin目录中删除只读标志后，这对我有帮助。 http://www.thewindowsclub.com/error-0x80080015-windows-defender-activation-requires-display-name

答案 26 :(得分：0)

我有同样的问题。它说无法从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个多小时调试这个，最后找到了自己的解决方案。

这是正确答案。

答案 27 :(得分：0)

我在VS2013中发现我经常收到此错误。似乎运行良好的东西是在尝试运行应用程序之前执行重建解决方案。我发现执行CLEAN有时会起作用，但重建解决方案似乎更一致。

答案 28 :(得分：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”的范围更改为函数外部，或者在Task.Factory.StartNew();之后不使用“a”后，我能够再次构建。

在Windows7x64 sp1上使用VS2012 Update 4时发生这种情况。

错误讯息：

  

C：\的Windows \ Microsoft.NET \框架\ v4.0.30319 \ Microsoft.Common.targets（3390,5）：   错误MSB3030：无法复制文件“obj \ x86 \ Debug \ xxx.exe”，因为   它没有找到。

答案 29 :(得分：0)

对于使用WCF的Windows服务，我结束了WFC主机进程并且它工作正常。当这种情况发生时我讨厌它，有时会随机发生。

答案 30 :(得分：0)

当我遇到类似问题时，唯一似乎有用的是：

  • 右键单击项目，转到“设置”，确保“调试”和“发布”构建都针对相同的设置，或者在那里设置应用程序尝试加载或保存的设置。
  • 删除C：\ Users（YourUserAccount）\ AppData \ Local（YourAppName）文件夹。
  • 确保我在那里没有的文件被视为“已屏蔽”。右键单击我项目的包含文件，我意识到一个图标实际上被阻止并被认为是坏的，因为它是从互联网上下载的。我必须单击“取消阻止”按钮（例如，请检查出来：http://devierkoeden.com/Images/Articles/Dynamicweb/CustomModules/Part1/BlockedFiles.png - “此文件来自另一台计算机，可能会被阻止以帮助保护此计算机。”）。

答案 31 :(得分：0)

我知道这是一个非常古老的问题，但我最近在VS 2012中经历了“无法从obj复制到bin”错误。每次我尝试重建某个项目时，都收到了消息。唯一的解决方案是在每次重建之前进行清理。

经过大量调查后发现，我的一个文件中有一个不完整的pragma警告语句，这个语句并没有阻止编译成功，但是在某种程度上混淆了VS以防止文件被锁定。

就我而言，我在文件顶部有以下内容：

#pragma warning(

就是这样。我想我曾经试图做一些事情并且分心并且从未完成过程，但关于那条特定线路的VS警告在洗牌中丢失了。最后我注意到了警告，删除了线，并且从那时起每次重建都有效。

答案 32 :(得分：0)

其他答案都没有对我有用，但关闭Visual Studio中所有打开的标签似乎已经解决了问题。

答案 33 :(得分：0)

先做简单的事情。

检查解决方案的某些部分是否未被正在运行的进程锁定。

例如，我在我的Windows服务上运行“InstallUtil”（我通常从控制台进行单元测试）。

这将我的一些dll锁定在Windows服务项目的bin文件夹中。 当我进行重建时，我在这个问题上得到了例外。

我停止了Windows服务，重建并成功了。

在执行此问题中的任何预先步骤之前，请检查应用程序的Windows任务管理器。

所以当你听到脚步声时，想想马不是斑马！ （来自医学生朋友）

答案 34 :(得分：0)

我尝试了您提供的几种解决方案，但有时我仍会收到此错误。我很肯定我的进程没有运行，当我尝试用Internet Explorer删除可执行文件时，它会从文件列表中删除，但是然后我按F5并瞧，文件又回来了。它根本没有被删除。

但如果我通过TotalCommander删除文件，exe文件实际上已删除，我可以成功构建项目。

我使用的是Windows 7 x64和总指挥官7.56a 32位。

相关问题
最新问题