Visual studio 2010 msbuild中的增量清理是什么，何时触发？

我正在调试构建过程中偶尔出现的一个bug，但我无法直接复制它。我正在对teamcity使用msbuild

我有这样一个依赖层次结构：

Some.Interop.dll
   Dependency-> SharedDllABC.dll

SomeService.exe
   Depenendcy-> Some.Interop

通常，最终的可执行服务位于其发布目录中：

Some.Interop
SharedDllABC.Dll
ServiceExectuable.exe

但是，我可以在我们的msbuild日志中看到，有时在构建所有内容后的增量清理过程中删除第三级依赖项，从而导致：

Some.Interop
ServiceExectuable.exe

您可以在msbuild日志中看到它：

[src\SomeService\SomeService.csproj] _TimeStampAfterCompile
[12:32:43]:  [src\SomeService\SomeService.csproj] Compile

// some other targets

[12:32:43]:  [src\SomeService\SomeService.csproj] _CopyFilesMarkedCopyLocal
[12:32:43]:      [_CopyFilesMarkedCopyLocal] Copy
[12:32:43]:          [Copy] Copying file from "C:Projects\trunk\src\Some.Interop\bin\Release\Some.Interop.dll" to "bin\Release\Some.Interop.dll".

// some other targets

[src\Project\SomeService\SomeService.csproj] IncrementalClean
[18:54:42]:         [IncrementalClean] Delete
[18:54:42]:             [Delete] Deleting file "C:\Projects\trunk\src\Project\SomeService\bin\Release\SharedDllABC.dll".
[18:54:42]:             [Delete] Deleting file "C:\Projects\trunk\src\Project\SomeServiceService\bin\Release\SharedDllABC.pdb".
[18:54:42]:     [src\Project\SomeService\SomeService.csproj] CoreBuild
[18:54:42]:     [src\Project\SomeService\SomeService.csproj] AfterBuild
[18:54:42]:     [src\Project\SomeService\SomeService.csproj] Build

这是我的直接msbuild输出，我刚刚更改了项目名称/dll名称以匹配我的示例。在进行此增量清理时，

SomeService.csproj

已经生成。你可以看到它没有被复制。但是，在其他msbuild日志中，它确实被正确复制，然后增量清理不会删除它

我认为incrementeal clean from应该清理从以前的构建中创建的dll，但这并不能解释为什么这个dll在大多数情况下无法构建。在VisualStudio中，这也始终有效

我想我只是想知道什么是增量清理，是什么导致它启动，也许在调试这样的情况时应该寻找什么东西（程序集版本、时间戳等？

尝试以下方法：

加：

到包含在所有项目中的.targets文件

---

从-->

这可能是由MsBuild中的错误引起的：。 评论中提出了一个解决方案：

当MsBuild确定要从引用的项目复制哪些项时，它应该递归执行此操作，但不能正确执行此操作

作为一种解决方法，可以在每个csproj中添加以下内容

<Target
    Name="ForceAssignProjectConfigurationBeforeSplitProjectReferencesByFileExistence_KLUDGE" 
    BeforeTargets="_SplitProjectReferencesByFileExistence" 
    DependsOnTargets="AssignProjectConfiguration" 
/>

---

@Kebabbi建议通过编辑csproj文件进行修复。从MSBuild 15开始，有一种简单的方法可以将此应用于所有CSPROJ文件，而不是编辑每个CSPROJ文件

Directory.Build.props和Directory.Build.targets 在MSBuild版本15之前，如果希望为解决方案中的项目提供新的自定义属性，则必须手动将对该属性的引用添加到解决方案中的每个项目文件中。或者，您必须在.props文件中定义属性，然后在解决方案中的每个项目中显式导入.props文件

但是，现在您可以通过在包含源代码的根文件夹中名为Directory.Build.props的单个文件中定义新属性，一步向每个项目添加新属性。运行MSBuild时，Microsoft.Common.props会在目录结构中搜索directory.Build.props文件（Microsoft.Common.targets会查找directory.Build.targets）。如果找到一个，则导入属性。Directory.Build.props是一个用户定义的文件，为目录下的项目提供自定义设置

创建一个文件

Directory.Build.props

，并将其放置在SLN文件旁边

<Project>
   <Target
     Name="ForceAssignProjectConfigurationBeforeSplitProjectReferencesByFileExistence_KLUDGE" 
     BeforeTargets="_SplitProjectReferencesByFileExistence" 
     DependsOnTargets="AssignProjectConfiguration" />
</Project>

---

我花了几天时间试图用类似的模式来解决这个问题。在我们的例子中，从输出文件夹中删除的是nuget文件

NugetPackage (that drops files in x86/x64 subfolders in output folder)

LibraryA.dll
   Dependency-> NugetPackage

LibraryB.dll
   Dependency-> LibraryA.dll

在我们的例子中，有许多解决方案文件是作为msbuild脚本的一部分按特定顺序构建的。 问题是LibraryB.csproj包含在两个解决方案文件中

Solution1生成和输出文件都存在

Solution2构建并查看LibraryB.dll是否存在并且是最新的，因此出于某种原因，会触发增量清理，从输出文件夹中删除NugetPackage文件

NugetPackage (that drops files in x86/x64 subfolders in output folder)

LibraryA.dll
   Dependency-> NugetPackage

LibraryB.dll
   Dependency-> LibraryA.dll

---

从解决方案2中删除LibraryB.csproj后，问题就解决了，文件也出现在输出文件夹中。

增量清理

在

c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets

中实现。这里面有很多逻辑。。。如果你想知道更多，在那里添加一些打印-

，也许你会看到这个逻辑是什么。我有非常类似的问题。你找到你的罪犯了吗？塞巴斯蒂安，我一直想不出来。我最终做的是从需要它的项目中创建对该文件的硬依赖关系。这并不理想，但确实有效。我的团队提出的其他一些解决方案是创建单元测试来测试预期的dll，这至少可以防止失败的构建被发送到客户端/测试机器。啊！谢谢你的更新。我必须坚持下去，在这里解决问题。您是使用MSBuild或通过Visual Studio（live或使用devenv.exe？）从命令行生成的吗？当我尝试通过MSBuild生成包时，我的项目中出现了此问题

msbuild.exe/t:Package

我不知道为什么增量清理会删除依赖的dll，但使用显式重建会阻止此

msbuild.exe/t:rebuild；Package

new.csproj格式（.NET SDK）如何，此解决方案在这些设置下不起作用

false

false

path\to\bin\$（配置）\

NugetPackage (that drops files in x86/x64 subfolders in output folder)

LibraryA.dll
   Dependency-> NugetPackage

LibraryB.dll
   Dependency-> LibraryA.dll