无法将文件从obj \ Debug复制到bin \ Debug
我在C＃中有一个项目，每次尝试编译项目时都会出现此错误：
（无法将文件“obj \ Debug \ Project1.exe”复制到“bin \ Debug \ Project1.exe”。进程无法访问文件“bin \ Debug \ Project1.exe”，因为它正在被另一个进程使用。
…所以我必须closures任务pipe理器的过程。 我的项目只有一种forms，没有multithreading。
什么是解决scheme（不重新启动VS或杀死进程）？
这是我们如何解决这个问题的错误代码？
@Udpate：自从我第一次发布这个“答案”以来，我倾向于对这个问题进行另一种解释。 由于这个问题比Visual Studio更经常发生，试图将一个.exe文件从一个文件夹复制到另一个文件夹。 虽然Windows首先不允许复制（！）一个.exe文件（它首先要求我提供pipe理权限，但不pipe怎么样都拒绝复制），但它仍然出现在资源pipe理器中。 但过了一段时间，没有采取任何进一步行动，它神奇地消失了。 就像这个问题的问题似乎总是在一段时间后解决。 所以我认为，这个问题更多地涉及项目输出文件的延迟删除，减less了一个越野车VS. 对于任何不合理的怀疑，我表示歉意。 ：|
这让我find了一个完全不同的方向，我猜。 find了链接，并会更新任何进度：
https://superuser.com/questions/234569/windows-7-delayed-file-delete
================================================== ======================
这是VS中的一个已知的错误。 我经常发现它 – 主要在VS2010中（有/无SP1）。 推荐几个“解决scheme”。 其中有些对我有帮助：
- 删除项目目录中的.suo文件。 最终需要从头开始创build整个解决scheme。
- closures任何Windows窗体devise器可能保持打开。
- 使用预生成脚本，从输出目录中删除目标。
- 禁用VS托pipe过程。
这些都没有真正解决这个错误。 但它可能会使VS回到可用状态 – 直到MS提供一个真正的解决scheme（如果将来）。
http://social.msdn.microsoft.com/Forums/en/vsdebug/thread/cea5e4b2-5b33-453c-bffb-8da9f1a1fa4a
http://social.msdn.microsoft.com/Forums/en/vbide/thread/cd12f3c7-de96-4353-adce-23975e30933f
我也可以确认VS 2012 Update 2中存在这个错误。
我的解决方法是：
- 清洁解决scheme（除此之外别无其他）
- closures解决scheme中所有打开的文档/文件
- 退出VS 2012
- 运行VS 2012
- 构build解决scheme
我不知道这是否相关，但我的项目在其他项目的类文件中使用“Linked” – 这是一个Silverlight 5项目，共享.NET和SL兼容类的唯一方法是链接文件。
需要考虑的事情…在单个解决scheme中跨项目查找链接的文件。
如果您在obj目录中查看，并且没有看到您的.exe文件，则可能是Avast！ 或其他杀毒软件正在删除它。 我真的会看到.exe出现，然后消失。 一旦我关掉了Avast！，问题就解决了。
VS2010投掷“无法复制文件”obj \ x86 \ Debug \ [文件] .exe“，因为它没有被发现。
这应该工作。
转到您的项目属性。 在生成事件的内部，在预生成事件命令行下，添加以下两行代码：
if exist "$(TargetPath).locked" del "$(TargetPath).locked" if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked" 真正的问题不是你得到的错误; 这是应用程序本身没有清理。
它要么坚持引用，不要释放资源，要么导致过程在告知closures时不结束。 解决这个问题，这个问题将自行解决。 我们不能真正帮助你，除非你发布你的代码（在这一点上，如果你需要帮助，你应该开始一个新的问题）。
这是因为[yourProjectName].exe进程在完成debugging后未closures。
有两个解决这个问题的方法。
-
每次你改变应用程序，转到任务pipe理器 – >进程 – > [yourProjectName] .exe，结束这个过程。 每次更改系统时都必须结束此过程。
-
在应用程序中添加一个退出button以退出窗口，并将这些行添加到单击事件中
System.Diagnostics.Process.GetCurrentProcess().Kill(); Application.Exit();
在看到2012年的视觉工作室出现类似的错误没有在哪里。 我发现，去项目的根文件夹，并右键点击它我没有选中只读，这个错误消失了。 显然TFS有时会使文件夹只读。 希望这会帮助任何有类似问题的人。 谢谢
我不得不进入Windows资源pipe理器，删除bin / debug文件夹以及obj / debug文件夹。 然后我清理并重build了这个项目。
这发生在VS 2010和Win 7的我身上。案例：
- 我不能用debuggingconfigurationpipe理器重build，但我可以用发布configurationpipe理器重build
我曾经尝试过：
- 在控制面板检查我的帐户types – 用户帐户 – >我的帐户是pipe理员
- 设置bin文件夹不是只读的
- 将bin文件夹中的安全性添加到Everyone
- 停止iis服务器
-
停止杀毒软件，使用任务pipe理器和ProcessExplorer检查可笑的运行程序
-
以pipe理员身份运行VS
如果所有这一切仍然无法正常工作。
那么，最后的尝试方法是：
- closures解决scheme
- closures视觉工作室
- 开始 – 关机
- 按电源button打开电脑
- login到用户types具有pipe理员权限的帐户
- 重新打开解决scheme
- 重build
- 这样工作。 所有人都这样称呼重置计算机
如果其他build议不适合你，在这个URL提出的解决scheme帮助我： http : //weblogs.asp.net/fmarguerie/archive/2009/01/29/life-changer-xaml-tip-for-visual-studio的.aspx
这个问题也与此问题有关： VS2012 – 当Xaml文件打开时，XDesProc挂起
由于某种原因，当我打开XAML文件，然后build立，XDesProc进程留在内存中，同时使用主要的dll文件
在重build解决scheme之前， 清除项目 ，停止IIS并打开“bin”文件夹属性。 取消选中常规选项卡中的只读属性 ，然后重新生成。
我有同样的问题，在阅读你的答案后，去Task Manager ，searchapp.exe因为我相信也许它不closures。
find它，select它并做END TASK解决。
- closures你的项目
- 删除bin文件夹
我觉得它的工作，:)
以Administrator身份运行Visual Studio
我们最近在VS 2012 Update 2上的WinPhone 8项目中体验到了这一点。
令人费解的是，原因是使用Tupletypes。 删除使用Tuple的代码，问题就消失了。 添加代码返回问题返回。
这听起来很疯狂，当我build立项目的错误将显示和avast防病毒将显示它作为恶意尝试和项目不run.i只是简单地禁用我的杀毒软件，并再次构build我的解决scheme，缺less的.EXE文件已创build并且项目已成功执行。
或者你可以试试这个
Visual Studio构build失败：无法将exe文件从obj \ debug复制到bin \ debug
我通过杀死XDesProc来解决这个问题，它有一个无法删除的DLL句柄。
那么我有同样的问题，我的方法来解决它是停止和禁用Windows中的“应用程序体验”服务。
不是你的问题的直接答案..
下面列出了一种情况：
如果您的应用程序在debugging过程中 – 比如说“附加到进程”debugging，则可能会出现此错误
我发现结束所有msbuild.exe任务（在任务pipe理器中）解决了VS2012的问题。
如果遇到此错误，则可按以下步骤进行操作
- 结束
msbuild.exe任务 - 结束
explorer.exe任务 - 再次运行
explorer.exe任务
对我来说这是杀毒软件。 只需将Visual Studio项目或整个父文件夹添加到防病毒排除列表中，或者也可以添加文件扩展名作为排除，并且此方法在visual studio 2010中为我工作
解决方法1：
- closures该项目。
- 删除bin文件夹。
- 打开项目。
- build立这个项目。
溶液2：
在预生成事件中添加以下代码：
attrib -r $(OutDir)*..\* /s
这个命令行代码将删除“bin”文件夹的ready-only属性。 现在，visual studio可以轻松删除和复制新的dll。
多年以来，我一直为此而苦恼。 我终于下载了LockHunter来找出谁locking了这个文件。 在我的情况下，这是MBAM。 一旦我将我的项目的目录添加到MBAM排除列表，我没有这个问题了。
