0

マルチターゲット ビルドのコンテキストで $(OutputPath) 内のファイルに対して操作を実行するために、sdk スタイルのプロジェクトでカスタム ターゲットを作成する標準的な方法は何ですか? 私は net5 への移行のためにビルドをマルチターゲットしようとしていますが、これがいかに厄介であるかに驚いています。ビルドの一部としてファイルをコピーしたり、exe を実行したりするために $(OutputPath) に到達する必要があるさまざまなターゲットがあります。たとえば、次のようなターゲットです。

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

$(OutputPath) が実際に Foo.exe がある bin\debug に設定されているため、これはマルチターゲットのない sdk スタイルのプロジェクトで正常に機能しました。しかし、上記では、AppendTargetFrameworkToOutputPath が $(OutputPath) を bin\debug\net48 に設定する作業を行う前に、ItemGroup が評価されます。そのため、私の ItemGroup は bin\debug\net48 ではなく bin\debug で Foo.exe を探しています (これは $(TargetFramework) が定義されている内部ビルドでも当てはまります)。AppendTargetFrameworkToOutputPath に依存する代わりに、Directory.Build.props で $(OutputPath) を bin$(Configuration)$(TargetFramework) として自分で定義しようとしましたが、$(TargetFramework) は csproj コンテンツの後まで sdk によって設定されないためです。同じ問題が発生します ($(OutputPath) を使用する ItemGroup 内のパスは bin\debug\ に評価されます)。

いくつかの回避策を考案できますが、それらはすべて少しハックに思えます (たとえば、実行時に $(OutputPath) が完全に構築されるように、将来のターゲットの入力/出力用に ItemGroups を定義することだけが仕事である前のターゲットを定義します)。マルチターゲティングのドキュメントで、この機能を使用すると、ビルド プロセスの一部としてビルド アーティファクトを参照する能力が実際に台無しになるとは言及されていないようでした。

4

0 に答える 0