MsBuild：使用 CallTarget 传递 ItemGroup
我在 MSBuild 脚本中创建的项目组的范围方面遇到一些问题。基本上，我想要做的是有两个不同的目标 - 让我们称它们为 RunUnitTests 和 RunIntegrationTests - 生成一个名为 TestAssemblies 的项目组并然后调用 RunTests，它使用 TestAssemblies 来确定从哪些程序集运行测试。
单元测试和集成测试的两个不同目标都依赖于构建目标，并从那里获取包含所有已编译程序集的项目组，但由于将从不同位置调用 RunTests 目标，因此它不能确实取决于他们中的任何一个。因此，我需要以某种方式将项目组传递给通用测试运行器目标。然而，这似乎是不可能的，因为对目标内的项目组的更改似乎仅限于该目标内。
我见过这些 帖子，但是他们似乎只是证实了我的恐惧，并建议 DependsOnTarget 作为解决方法 - 这对我不起作用，因为我需要在不同的运行中从不同的地方获取项目。
这就是我到目前为止所拥有的：
<Target Name="RunAllTests" DependsOnTarget="BuildProject">
<!-- In here, items created in BuildProject are available. -->
<CallTarget Targets="RunUnitTests;RunIntegrationTests">
</Target>
<Target Name="RunUnitTests" DependsOnTarget="BuildProject">
<!-- In here, items created in BuildProject are available. -->
<!-- One of those is @(UnitTestAssemblies) -->
<CreateItem Include="@(UnitTestAssemblies)">
<Output TaskParameter="Include" ItemName="TestAssemblies" />
</CreateItem>
<CallTarget Targets="RunTests" />
</Target>
<!-- Then there's a similar target named RunIntegrationTests, which does the
same as RunUnitTests except it includes @(IntegrationTestAssemblies) -->
<Target Name="RunTests">
<!-- Here, I'd like to access @(TestAssemblies) and pass them to the NUnit
task, but they have fallen out of scope. -->
</Target>
有什么办法可以解决这个问题，或者我必须完全重组我的构建脚本吗？
I'm having some problems witht the scoping of item groups I create in an MSBuild script. Basically, what I want to do is to have two different targets - let's call them RunUnitTests and RunIntegrationTests - that generate an item group called TestAssemblies and then call RunTests, which uses TestAssemblies to determine which assemblies to run tests from.
The two different targets for unit and integration tests both depend on the build target and get an item group with all compiled assemblies from there, but since the RunTests target will be called from different places, it can't really depend on either of them. Thus, I need to pass the item group to the common testrunner target somehow. However, this seems to be impossible, because changes to an item group within a target seems to be scoped to only work within that target.
I've seen these posts, but they only seem to confirm my fears, and suggest DependsOnTarget as a workaround - which won't work for me, since I need to get the items from different places on different runs.
This is what I have so far:
<Target Name="RunAllTests" DependsOnTarget="BuildProject">
<!-- In here, items created in BuildProject are available. -->
<CallTarget Targets="RunUnitTests;RunIntegrationTests">
</Target>
<Target Name="RunUnitTests" DependsOnTarget="BuildProject">
<!-- In here, items created in BuildProject are available. -->
<!-- One of those is @(UnitTestAssemblies) -->
<CreateItem Include="@(UnitTestAssemblies)">
<Output TaskParameter="Include" ItemName="TestAssemblies" />
</CreateItem>
<CallTarget Targets="RunTests" />
</Target>
<!-- Then there's a similar target named RunIntegrationTests, which does the
same as RunUnitTests except it includes @(IntegrationTestAssemblies) -->
<Target Name="RunTests">
<!-- Here, I'd like to access @(TestAssemblies) and pass them to the NUnit
task, but they have fallen out of scope. -->
</Target>
Is there any way around this, or will I have to completely restructure my build script?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对目标内的项目组所做的更改仅在更改的目标退出后对其他目标可见。因此，要保留测试程序集的列表，您可能必须将实际设置的目标移动到其自己的目标，如下所示：
Changes to an item group within a target are only visible to other targets after the changing target exits. So to get the list of test assemblies to stick, you may have to move actually setting up the targets to its own target as in the following:
在“MSBuild”任务中，您可以将属性传递给目标，但我不确定它是否适用于 ItemGroup。但你绝对可以通过批处理来做到这一点 - 一次传递一个程序集。
它一次只会运行一个程序集的“RunTests”，因此如果您在运行测试时需要了解其他程序集，它将毫无用处。但也许它会提供一些更好的想法来解决这个问题......
In "MSBuild" task you can pass properties to targets, but I'm not sure if it will work for ItemGroup. But you definitely can do it through batching - passing one assembly at a time.
It would run the "RunTests" for only one assembly at a time, so it will be useless if you need knowledge of other assemblies at time of running tests. But maybe it will give some better ideas how to resolve this problem...