我一直在重新设计我的自定义VC ++构建，以与新的TFS 2015 Build解决方案兼容。
问题是运行msbuild。我可以发布一个简化版本，但我的解决方案包含两个项目：
1 Makefile Project旨在构建所需的所有库，以及 1 .exe项目。
我在.exe项目中引用了makefile项目，因此.exe的构建会在需要时强制构建库。
我们看到的问题是，当我们使用解决方案的msbuild进行重建时，它首先重建库，然后当它到达.exe时，它会清理库项目，导致一些重建文件被删除然后阻止.exe文件的链接，因为.lib文件已被删除。
为什么要再次清理makefile项目？看起来当它到达.exe项目时，它会重新解析依赖项，并且不知道库项目已经重建了。
提前致谢。拉里
答案 0 :(得分：0)
如果多个项目位于同一文件夹中，Visual Studio会在编译下一个项目时尝试删除输出文件夹（通常是Debug或Release）。最好的解决方案是将每个项目放在单独的文件夹中。
答案 1 :(得分：0)
我没有详细介绍所有细节，但发生这种情况的原因是，在构建命令行时，重建exe项目会导致exe项目的Clean + Build，以及exe项目的Clean目标最终调用CleanReferencedProjects目标，这会导致在Makefile项目中调用Clean（以及之后的Build，也是如此）。
此CleanReferencedProjects以属性BuildingInsideVisualStudio和BuildProjectReferences为条件，因此VS内部构建无论如何都会跳过此步骤，因为BuildingInsideVisualStudio是真的，甚至记录了它：
直接从命令行构建项目时，请清除这些引用的项目 存在于磁盘上。对于IDE构建和命令行.SLN构建，解决方案构建管理器 照顾好这个。
BuildProjectReferences属性记录如下：
默认情况下，我们将构建（如果适用，清除）所有项目引用。但这可以用来禁用
因此，一种可能的解决方案是调用msbuild some.sln /t:Rebuild /p:BuildProjectReferences=False。在只有2个项目的情况下，这将正常工作，但我不能保证这将始终在更复杂的情况下工作，具有更多的项目间依赖性。
现在有一件事让我想知道：为什么我自己从未见过这种行为？答案在于我不经常使用makefile项目，而我使用的C ++项目略有不同：那里，Rebuid目标是根据Clean + Build定义的（而对于Makefile项目，它是一个独立的，单独的目标）。因此，当exe项目调用BuildProjectReferences时，它将在C ++项目中调用Clean，但这会导致
Target "Clean" skipped. Previously built successfully.
因为在调用C ++项目的重建时它已经称为Clean and Build。
所以另一个可能的解决方案是对Makefile项目做同样的事情。你说你的Rebuild有额外的要求;我不知道它们是什么，也不知道为什么需要它们（可以说Rebuild与Clean + Build没有相同的效果），但这可能会起作用，例如makefile项目中的这个（所有文件末尾的方式）：
<Target Name="Rebuild" DependsOnTargets="Clean;Build">
<!--additional requirements here perhaps?-->
</Target>
所有东西都正确地进行了滑动，而Clean / Build仅被调用一次。
如果这些解决方案都不适用，我不会立即看到另一种方法，而是从解决方案中删除makefile项目，并在解决方案之前在本地和TFS中手动构建它。