我试图找出一种无需显式声明 ItemGroup 即可从上下文访问 Items 的方法。
目前正在尝试复制任务：
<Copy SourceFiles="C:\blabla\**\*.*" DestinationFiles="%(?.RecursiveDir)" />
我可以用什么代替“？” 在上下文中选择项目？
原因是，我有一个通过 XSLT 生成的 MSBuild 项目文件，并且有未知数量的文件夹和文件（其中一些在目标文件夹下遵循不同的结构 - 在这种情况下，我打算使用不同的元数据代替RecursiveDir) 在输入 XML 中。是否可以在不需要声明大量 Itemgroups（或具有很多 Items 的 Itemgroup）的情况下实现这一点？
我试着搜索这个，但我发现的只是声明了 Itemgroups 的帖子。
@Alexey Shcherbak 写道：
您想在不明确声明项目本身的情况下引用项目元数据，所以我怀疑您能否做到这一点。复制任务也要求源文件应该是
ITaskItem[]类型（字面意思 - 它需要项目集合）。实际上，复制任务的 msdn 描述 有一个您可以遵循的确切示例，但您应该在里面声明带有嵌套项目子句的 itemgroup。您可能想知道如果您有一个包含大量文件的项目，它是否会使 MSBuild 变慢。答案是：这取决于 =)。你在巨大的文件集下的意思是什么数字=）。确实，MSBuild 引擎会发出并评估内存中的每个项目组，并且可能一个巨大的文件集可能会导致更大的内存占用。但是 MSBuild 不适合用作您选择的脚本语言（即使 powershell 在一个目录中存在 250K+ 个文件的问题，Windows 本身也存在问题）。如果您只需要执行复制而不访问完整元（递归目录除外） - 使用 Exec 任务并调用 robocopy.exe - 它比其他任何东西都更好（考虑到可用的开箱即用工具）。
作为补充 - 在我们声明具体工具不可接受之前，应该测试和评估大量数字。我认为一旦 MSBuild 可以处理大型解决方案 - 它可能会处理相当大的文件集。它只是资源/速度问题。但任何工具也都有其不可逾越的限制。
实际上我的意思不是 robocopy 扩展，而是en.wikipedia.org/wiki/Robocopy
robocopy.exe本身，您可以使用 Exec 任务轻松调用它。就“复制”速度而言，硬链接肯定是无与伦比的=）。但请记住 - 它仅适用于单个磁盘卷（因为它不是实际副本，它只是将另一个文件名添加到同一组字节 =））。如果您需要实际复制到另一个驱动器或通过网络 - robocopy 将再次闪耀 =)。PS：20k 文件远非我对巨大的定义；）我们处理了约 280k-300k 的小文件，汇总量约为 80Gb。用于管道的 Powershell 和用于实际位移动的 robocopy 赢得了这一轮。