上下文中的参考项目

Question

我正在尝试找出一种无需显式声明 ItemGroup 即可从上下文访问项目的方法。

目前正在尝试复制任务：

<Copy SourceFiles="C:\blabla\**\*.*" DestinationFiles="%(?.RecursiveDir)" />

我可以用什么来代替“？”在上下文中选择项目？

原因是，我有一个通过 XSLT 生成的 MSBuild 项目文件，并且有未知数量的文件夹和文件（其中一些在目标文件夹下遵循不同的结构 - 在这种情况下，我打算使用不同的元数据代替输入 XML 中的 RecursiveDir)。是否可以在不需要声明大量 Itemgroups（或具有很多 Items 的 Itemgroup）的情况下实现这一点？

我尝试搜索这个，但我发现的都是声明了 Itemgroups 的帖子。

Answer 1

@Alexey Shcherbak 写道：

您想在不明确声明项目本身的情况下引用项目元数据，所以我怀疑您是否能够做到这一点。此外，复制任务要求源文件应该是 ITaskItem[] 类型（字面意思 - 它需要项目集合）。实际上msdn description of copy task 有一个你可以遵循的确切例子，但你应该在里面声明带有嵌套项目子句的 itemgroup。

您可能想知道如果您有一个包含大量文件的项目，它是否会使 MSBuild 变慢。 答案是：这取决于 =)。你在巨大的文件集下的意思是什么数字=）。确实，MSBuild 引擎会发出并评估内存中的每个项目组，并且可能一个巨大的文件集可能会导致更大的内存占用。但是 MSBuild 不适合用作您选择的脚本语言（即使 powershell 在一个目录中存在 250K+ 文件的问题，Windows 本身也存在问题）。如果您只需要执行复制而不访问完整元（递归目录除外） - 使用 Exec 任务并调用 robocopy.exe - 它比其他任何东西都更好（考虑到可用的开箱即用工具）。

作为补充 - 在我们声明具体工具不可接受之前，应该测试和评估大量数字。我认为一旦 MSBuild 可以处理大型解决方案 - 它可能会处理相当大的文件集。它只是资源/速度问题。但任何工具也都有其不可逾越的限制。

其实我的意思不是robocopy扩展，而是robocopy.exe本身en.wikipedia.org/wiki/Robocopy，你可以很容易地用Exec任务调用它。就“复制”速度而言，硬链接肯定是无与伦比的=）。但请记住 - 它仅适用于单个磁盘卷（因为它不是实际副本，它只是将另一个文件名添加到同一组字节 =））。如果您需要实际复制到另一个驱动器或通过网络 - robocopy 将再次闪耀 =)。

PS：20k 文件远非我对巨大的定义；）我们处理了约 280k-300k 的小文件，总体积约为 80Gb。用于管道的 Powershell 和用于实际位移动的 robocopy 赢得了这一轮。