1

我一直在尝试使我的 TFS 构建中的任务更通用，我想做的一件事是根据使用该任务的构建将一些文件复制到不同的目录。我玩弄了使用属性的想法，但我想不出一种干净的方法，所以我尝试使用项目元数据，因为我已经能够在同一个目标文件的另一个地方这样做我正在努力，只是这一次，我想使用属性。

这是我想要做的：

<ItemGroup>
  <DestinationParent Include="$(DeploymentPath)">
    <DestinationParentPath>$(DeploymentPath)</QuartzParentPath>
  </DestinationParent>
</ItemGroup>

后来在构建中，我尝试通过引用项目元数据将一些文件复制到目标文件夹：

<Copy SourceFiles="@(FilesToCopy)" DestinationFiles="@(FilesToCopy-&gt;'%(DestinationParentPath)\Destination\%(RecursiveDir)%(Filename)%(Extension)')" ContinueOnError="false" ></Copy>

不幸的是，构建运行后，我的 BuildLog 显示以下内容：

Copying file from "$(BinariesRoot)\%(ConfigurationToBuild.FlavorToBuild)\<File being copied>" to "\Destination\<File being copied>".

%(DestinationParentPath) 已扩展为空字符串，无论出于何种原因。使用 %(DestinationParent.DestinationParentPath) 会产生错误，告诉我我应该简单地使用 %(DestinationParentPath)。$(DeploymentPath) 在构建中的其他几个地方按预期扩展为正确的字符串。

另一个混淆的来源是使用 %(ConfigurationToBuild.FlavorToBuild) 产生了正确的值，即 Test，如下所示：

编辑：这是在根节点 Project 下定义的，而具有 DestinationParentPath 的 ItemGroup 是在 Target 节点下定义的。这也有影响吗？

<ItemGroup>
  <ConfigurationToBuild Include="Test|Any CPU">
    <FlavorToBuild>Test</FlavorToBuild>
    <PlatformToBuild>Any CPU</PlatformToBuild>
  </ConfigurationToBuild>
</ItemGroup>

当您只对项目元数据中的字符串感兴趣时，似乎 Include 属性并不相关，因为我很确定“Test|Any CPU”没有引用任何实际文件。

那么再一次，为什么 %(DestinationParentPath) 扩展为一个空字符串？

编辑：我忘了提到我也尝试硬编码 DestinationParentPath 的实际路径，但这仍然导致 %(DestinationParentPath) 扩展为空字符串。

4

1 回答 1

1

编辑：这是在根节点 Project 下定义的，而具有 DestinationParentPath 的 ItemGroup 是在 Target 节点下定义的。这也有影响吗？

Yes, it makes a difference. The ability to define an ItemGroup inside a Target is new to msbuild 3.5. Despite looking declarative, it's actually executed at runtime just as if you'd called the old style CreateItem / CreateProperty tasks. That alone leads to potential issues: you need to consider when the containing task is (first) called. Order of operations is not always obvious to the naked eye. May be wise to make the task where you use %(DestinationParentPath) dependent on the task where it's created, even if there's no "logical" dependency.

In addition, there are the age-old msbuild scoping quirks/bugs. Dynamically created properties & items are not visible to "sibling" tasks. Also, items updated in nested builds aren't always bubbled up.

Check out the workarounds in the links, you should be able to find something that works for you even if it's icky.

于 2009-09-11T00:45:07.507 回答