Closed UtkarshPhilips closed 11 months ago
For multi-targeted projects, out-of-the-box support is currently provided through project-level target injection via NuGet, and relies on that being picked up under dotnet test
as a calling framework to provide the $TargetFrameworks
and current $TargetFramework
. Those values are used, where appropriate, just to add a label to the coverage output file.
Not knowing how you are invoking the Prepare
and Collect
tasks, it is difficult to advise in detail; but from what you have provided, if you are using AltCover.targets
across the board, it might as well be imported unconditionally, leaving any resolution of $TargetFrameworks
and $TargetFramework
to the point of use; and as you are quoting the path to the targets file, if you are indeed simply explicitly invoking those tasks, you might as well cut out the indirection, and include them directly
<UsingTask TaskName="AltCover.Prepare"
AssemblyFile="$(NuGetPackageRoot)altcover\8.6.68\lib\netstandard2.0/AltCover.Engine.dll" />
<UsingTask TaskName="AltCover.Collect"
AssemblyFile="$(NuGetPackageRoot)altcover\8.6.68\lib\netstandard2.0/AltCover.Engine.dll" />
as there is nothing there that depends on the target framework
Thank you for this report - it has taught me something about NuGet documentation. It seems the only references to buildCrossTargeting
and buildMultiTargeting
to be found are in various GitHub issues that I would otherwise have never had reason to investigate.
This is a pre-release build that moves the .targets
and .props
file up out of the netstandard20
folder. That it built means that it passed all my test cases, including multi-targeting, but I would like you to try it as well to see if it avoids having to use the workrounds posted above.
After much experimenting, I am forced to advise that this is not fixable without breaking all other MSBuild (dotnet test
) integration. Specifically, while a .nuget.g.targets
file can have an extra
<ImportGroup Condition=" '$(TargetFramework)' == '' AND '$(ExcludeRestorePackageImports)' != 'true' ">
...
<Import Project="$(NuGetPackageRoot)altcover\8.6.68\build\netstandard2.0\AltCover.targets" Condition="Exists('$(NuGetPackageRoot)altcover\8.6.68\buildMultiTargeting\AltCover.targets')" />
</ImportGroup>
clause, pointing at a different .targets
file, the whole .nuget.g.targets
only gets actioned once when it exists, but the existing multi-targeting for dotnet test
relies on it being actioned per-project.
I'm afraid that it has to come down to manually adding something like this to the project file -
<UsingTask TaskName="AltCover.Prepare"
AssemblyFile="$(NuGetPackageRoot)altcover\$(AltCoverVersion)\lib\netstandard2.0/AltCover.Engine.dll" />
<UsingTask TaskName="AltCover.Collect"
AssemblyFile="$(NuGetPackageRoot)altcover\$(AltCoverVersion)\lib\netstandard2.0/AltCover.Engine.dll" />
where $(AltCoverVersion)
is set in one place to be updated per new release.
Labelled "wontfix" but truly it's "can't fix". Sorry.
I've been recently migrating a few of my unittest projects, for a
netstandard2.0
main project, to multi-targetnet48
andnet6.0
for assuring compatibility. Since I'm using the AltcoverPrepare
andCollect
targets, I'd love to see them support multi-targeting projects out-of-the-box.My current setup:
Running the
coverage
target on my test project gives me the following output:Looking into the generated
obj\Example.Tests.csproj.nuget.g.targets
file, I can see the relevant import as follows:Since I have no
TargetFramework
set in outer build due to multi-targeting. I suspected, thePrepare
andCollect
targets were not imported.To test this, I manually imported the targets in the
csproj
and they started to work right away.I found a relevant issue raised in MSBuild for cross-targeting: https://github.com/dotnet/msbuild/issues/1860
According to the resolution from the issue, it seems moving targets to
buildCrossTargeting
allows them to be used in cross-targeting projects.Is this a viable path for AltCover as well? If not, can the imports be fixed without explicitly importing the targets file?
Thanks