Visual Studio 2010 构建文件锁定问题 [英] Visual Studio 2010 build file lock issues

问题描述

我有一个 Visual Studio 2008 项目，我升级"到了 Visual Studio 2010.自从升级以来，我在项目中遇到了很多问题(我可能会添加一个在 2008 年仍然是士兵的项目).

I have a Visual Studio 2008 project that I "upgraded" to Visual Studio 2010. Since the upgrade I have been having a lot of problems with the project (a project that was and still is trooper in 2008 I might add).

第一个问题是构建主可执行文件锁定了可执行文件，导致进一步的重建失败.这在相关问题中有所描述:Visual Studio locks output file on build 我在那里找到了解决方法:

The first problem is that building the main executable locks the executable, causing further rebuilds to fail. This is described in a related question: Visual Studio locks output file on build where I picked up the workaround:

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

除了这个变通办法完全一次.然后 .locked 文件也被 devenv.exe 锁定，必须移动.我一直在通过添加 .1.locked、.2.locked 等来解决这个问题. 删除锁以便文件可以删除的唯一时间是在 devenv.exe 关闭时(它UI消失后需要几秒钟，然后可以删除文件).

Except this workaround works exactly once. The .locked file then is locked by devenv.exe as well and must be moved. I have been working around this by adding .1.locked, .2.locked, etc. The only time that the locks are removed so the files can be deleted is on shutdown of devenv.exe (it takes a few seconds after the UI vanishes, then the files can be removed).

不必使用调试器来导致此问题这一事实表明 2010 构建系统存在相当严重的问题.

The fact that the debugger does not have to be used to cause this problem points to a pretty serious issue with the 2010 build system.

我认为我可以打折扣的一些理论:

Some theories I think I can discount:

• 防病毒或其他后台任务:如果这是一个问题，2008 似乎会失败.然而，作为一个完整的我删除了avast！系统完全没有运气.

更新:该项目在没有防病毒软件和备份实用程序的机器上具有相同的症状.办公室的机器运行的是XP SP3 32位，我的本地机器是Windows 7 64位.这似乎与操作系统无关.

UPDATE: This project has the same symptoms on a machine with no antivirus and no backup utility. The machines in the office are running XP SP3 32bit, my local machine is Windows 7 64 bit. This appears to be OS independent.

• 调试器正在锁定文件:重现此文件所需的只是重复构建过程而不进行调试.ProcessExplorer 显示 devenv.exe 是锁的持有者，而不是 vshost 并且杀死 vshost.exe 无论如何也不会删除锁.

我有一个次要问题，一旦文件被锁定，就会开始出现:表单设计者停止加载，并出现找不到程序集"错误.我怀疑这些与早期的锁定问题有关，因为设计师在构建之前立即启动，但是进行任何更改和重建都会导致所有设计师因该错误而崩溃(即使是我打开的设计师)并作为当前视图).

I have a secondary problem that starts to occur once the files get locked: the form designers stop loading with a "can't find assembly" error. I suspect these are related to the earlier locking issue as the designers fire right up prior to a build, but making any changes and rebuilding will cause all the designers to collapse with that error (even ones I have open and as the current view).

仅仅因为您将dummy=1"更改为dummy=2"而看到接近白色错误屏幕的表单是很可怜的，其中dummy"除了强制在完全不相关的程序集中重新编译之外什么都不做.

It is pitiful to watch a form close to the white error screen just because you changed "dummy=1" to "dummy=2" where "dummy" does absolutely nothing but force a recompile in a completely unrelated assembly.

更新:我尝试了更多补救措施:未选中启用 .NET 源步进，因此这不是问题.删除 .SUO(解决方案用户选项)只要重新启动通常会消除问题就可以正常工作(两个构建:第一个因为没有锁定文件，第二个因为有一个，但可以通过脚本重命名).

Update: I have tried a few more remedies: Enable .NET source stepping is not checked, so that isn't the issue. Removing the .SUO (solution user options) simply works for as long as a restart would normally remove the problem (two builds: the first because there is no locked file and the second because there is one, but it can be renamed by the script).

Error   28  Unable to copy file "obj\Debug\PolicyTracker3.exe" to "bin\Debug\PolicyTracker3.exe". 
The process cannot access the file 'bin\Debug\PolicyTracker3.exe' because it is being used by another process.  

推荐答案

在为此推出补丁之前，我有以下解决方法.只需使用类似 "C:\MyBin\VisualStudioLockWorkaround.exe" "$(TargetPath)" 之类的东西调用(用您放置可执行文件的位置替换 MyBin).

Until a patch rolls around for this, I have the following workaround. Simply call using something like "C:\MyBin\VisualStudioLockWorkaround.exe" "$(TargetPath)" (replacing MyBin with the location you place the executable).

将其创建为 C# 控制台应用程序，并以与原始预构建重命名相同的方式在预构建部分中使用(有关详细信息，请参阅原始问题的顶部).

Create this as a C# console application and is used in the Pre-Build section in the same way the original pre-build rename was (see the top of the original question for details).

 using System;
 using System.IO;

 namespace VisualStudioLockWorkaround
 {
  class Program
  {
   static void Main(string[] args)
   {
    string file = args[0];
    string fileName = Path.GetFileName(file);
    string directory = Path.GetDirectoryName(args[0]);
    if (!Directory.Exists(directory)) //If we don't have a folder, nothing to do.
    {
     Console.WriteLine(String.Format("Folder {0} not found. Exiting.", directory));
     return;
    }
    if (!File.Exists(file)) //If the offending executable is missing, no reason to remove the locked files.
    {
     Console.WriteLine(String.Format("File {0} not found. Exiting.", file));
     return;
    }
    foreach (string lockedFile in Directory.EnumerateFiles(directory, "*.locked"))
    {
     try //We know IOExceptions will occur due to the locking bug.
     {
      File.Delete(lockedFile);
     }
     catch (IOException)
     {
      //Nothing to do, just absorbing the IO error.
     }
     catch (UnauthorizedAccessException)
     {
      //Nothing to do, just absorbing the IO error.
     }                                        
    }

    //Rename the executable to a .locked
    File.Move(file, Path.Combine(directory, String.Format("{0}{1:ddmmyyhhmmss}.locked", fileName, DateTime.Now)));
   }
  }
 }

这篇关于Visual Studio 2010 构建文件锁定问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！