输出参数“CopiedFiles”复制任务返回指定要复制的所有文件，即使它在给定 SkipUnchangedFiles=“true”的情况下不复制任何内容。
CopiedFiles 参数返回所有要复制的文件。但考虑到 SkipUnchangedFiles 设置为 true 并且 ttask 本身没有复制任何内容，如命令行上所示（没有复制消息）。那么为什么 CopiedFiles 不为空呢？
我需要仅使用实际复制的文件（因为它们已更改）填充 CopiedFiles 参数，以便进一步将这些文件复制到其他文件夹中。这是为了维护最新的发布文件夹，并仅提取那些实际需要传播到 UAT/生产服务器上的文件。
为了便于参考，我正在使用的复制任务代码如下：
<Copy SkipUnchangedFiles="true"
SourceFiles="@(cfile)"
DestinationFiles="@(cfile->'$(PublishDir)\%(Identity)')">
<Output
TaskParameter="CopiedFiles"
ItemName="Changed" />
</Copy>
<Message Text="changed:@(Changed)" Importance="high" />
复制任务中是否存在错误，或者这是预期的行为。
The CopiedFiles parameter is returning all the files that were intended to be copied. But given the fact that SkipUnchangedFiles is set to true and ttask itself is not copying anything as can be seen on command line (no copying message). Why not, then, CopiedFiles is empty?
I need to have CopiedFiles parameter be populated only with files that were actually copied (because they were changed) in order to further copy these files into some other folder. This is to maintain an up-to-date release folder as well as to extract only those files which actually need to be propogated onto UAT/production server.
For reference sake, the copy task code I'm using is given below:
<Copy SkipUnchangedFiles="true"
SourceFiles="@(cfile)"
DestinationFiles="@(cfile->'$(PublishDir)\%(Identity)')">
<Output
TaskParameter="CopiedFiles"
ItemName="Changed" />
</Copy>
<Message Text="changed:@(Changed)" Importance="high" />
Is there a bug in the copy task or this is the intended behavior.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您所看到的行为是设计使然的。 MSBuild 使用任务输出跟踪文件依赖关系。如果不这样做，则在大多数情况下，任何依赖 @(Changed) 项数组作为输入的内容都无法完全处理所需的所有文件。出于同样的原因，它甚至会跟踪在目标中创建的属性和项目，这些属性和项目在输入和输出是最新时甚至不会执行。考虑使用附加输出参数 CopiedFilesCopiedByTask 创建一个您自己的不同复制任务（此命名反映了已失效的 CreateProperty 任务中 ValueSetByTask 的命名和行为）。
The behavior you are seeing is by design. MSBuild keeps track of file dependencies using task outputs. If it were to do otherwise, anything that relied on the @(Changed) item array as an input would not fully process all of the files it needed in most cases. It will even keep track of properties and items created within targets that don't even execute when Inputs and Outputs are up-to-date, for the same reason. Consider making a different Copy task of your own with an additional output parameter, CopiedFilesCopiedByTask (this naming mirrors the naming and behavior of the ValueSetByTask in the otherwise defunct CreateProperty task).