0

现在在 sdk 风格的项目中编写自定义目标以在多目标构建的上下文中对 $(OutputPath) 中的文件执行操作的规范方法是什么？我正在尝试多目标我们的构建以迁移到 net5，我很惊讶这是多么混乱。作为构建的一部分，我们有各种目标需要访问 $(OutputPath) 来复制文件或运行 exe 等。例如，像这样的目标：

<TargetFrameworks>net48;net5</TargetFrameworks> 
<AppendTargetFrameworkToOutputPath>true</AppendTargetFrameworkToOutputPath>
...
<ItemGroup>
    <MyTargetInputs Include="$(OutputPath)\Foo.exe">
</ItemGroup>
<Target Name="DoPostBuildStuff" AfterTargets="Build" Inputs="@(MyTargetInputs)" Outputs="@(MyTargetOutputs)">
    ...
</Target>

这在没有多目标的 sdk 样式项目中运行良好，因为 $(OutputPath) 设置为 bin\debug，这确实是 Foo.exe 所在的位置。但是通过上述，ItemGroup 在 AppendTargetFrameworkToOutputPath 执行其工作以使 $(OutputPath) 设置为 bin\debug\net48 之前得到评估。所以现在我的 ItemGroup 仍在 bin\debug 而不是 bin\debug\net48 中寻找 Foo.exe（即使在定义 $(TargetFramework) 的内部构建中也是如此）。作为依赖 AppendTargetFrameworkToOutputPath 的替代方法，我尝试在 Directory.Build.props 中将 $(OutputPath) 自己定义为 bin$(Configuration)$(TargetFramework) 但因为 $(TargetFramework) 直到我的 csproj 内容之后才由 sdk 设置被评估时会发生同样的问题（我的 ItemGroup 中使用 $(OutputPath) 的路径评估为 bin\debug\）。

我可以设计一些变通方法，但它们似乎都有些笨拙（例如，定义一个先前的目标，其唯一的工作是为未来目标的输入/输出定义 ItemGroups，以便 $(OutputPath) 在它运行时完全构建）。我很惊讶多目标文档似乎没有提到使用此功能真的会干扰您将构建工件作为构建过程的一部分引用的能力？

4

0 回答 0