终于解决了一个Win7 下 VS 编译的问题，困扰了我好几个月

      这个问题其实并不是VS的问题，只是因为我用VS需要经常编译并生成exe文件，所以才会表现的比较突出。它本质上其实是操作系统本身的问题，其表现为如果你运行了一个exe文件，当关闭这个进程后，你删除它，在资源管理器中你会看到它被删除了，但一刷新它又出现了，要等待大约5分钟左右，这个文件才会实际被删除掉，在此期间你无法对这个文件覆盖或改名。体现在VS开发环境中就是一旦你编译完运行过一次这个程序，你后面再编译，就报进程正在使用，无法覆盖，要等5分钟后才好。这个等待的时间时长时短，故障也不是每次都出现，不同的exe文件出现的频率也不一样。

       我之前在google 和 百度中搜索过很多次，中文和英文论坛中都有很多人遇到这个问题，基本上回答者给出的解决方案有以下几种：

       1. 第三方杀毒软件在作怪

       这个是最容易联想到的，在MSDN 的英文论坛上，我看到一个来自微软的工程师就是这么回答的，他坚决否认是操作系统引起的。由于他代表微软回答问题，这个很有一些误导性。实际上我停用了我的杀毒软件，还是无法解决这个问题，论坛上遇到相同问题的人也是一样。

       2. Indexing service 引起

       这种说法也是想当然的，认为Indexing service 在后台工作，可能会访问这个文件，导致无法删除。但这个说法有个问题他无法解释，就是为什么只有exe文件才出现这个问题？不管怎么样，我禁用了 Indexing service 这个服务，结果依然无法解决这个问题。

       3. 权限不够造成

       这个说法也比较荒谬，权限不够那应该永远无法删除才对，而且出错信息不应该是进程正在使用。我给了所在目录最高权限，依然无法解决这个问题。

      为了证实这个问题到底是操作系统的问题还是应用程序的问题，我尝试了下面方法

      1. 用 ProcessExplorer 来看对应的exe 文件有没有进程在占用

      结果是没有进程在占用。

      2. 将 exe 文件所在的目录做了审核，看删除后到底谁又把它重新创建了，因为删除后从表象上看，刷新一下，进程又出来了，所以我怀疑有什么进程重新创建了这个exe文件。

      结果当删除后，审核的日志中报告删除成功，之后没有重建的日志，而此时资源管理器中仍然能看到这个文件，而且无法覆盖和改名。

      由此我基本判断这个问题是操作系统引起的，和其他应用程序占用无关，exe 被删除后，操作系统中出现了不一致。很长一段时间我一直没有找到解决方案，因此我对win7 操作系统抱有成见，因为这个问题实在是个很严重的问题，这么多人都遇到过，居然都没有去fix 这个bug。不过今天我终于找到了解决方案，看来不是bug，而是使用不当造成，至于为什么会出现这个问题，我还没有搞清楚。

      问题的原因是 Application Experience 这个服务被关闭造成的，其实还有一个服务叫Program Compatibility Assistant Service 也要运行，只有这个两个服务同时运行，才不会出现这个删除不掉exe 的问题。