Open
Description
hello
I am hitting an error where when I run our benchmarks out of process with target net7.0 (like this: dotnet run -c release --framework net7.0 -r win-x64),
Bechnmarkdotnet generates a csproj named "BenchmarkDotNet.Autogenerated" that contains the following configuration:
net7.0
but because this project is part of a solution where Directory.Build.Props is used with configuration:
netstandard2.0;net7.0
the configuration TargetFrameworks takes precedence over TargetFramework and i get error:
error NU1201: Project is not compatible with netstandard2.0.
is there a way to configure benchmarkdotnet to put TargetFrameworks in the generated project instead of TargetFramework?
or any other way to get around this problem
thank you for your help
Metadata
Metadata
Assignees
Labels
No labels
Activity
timcassell commentedon Jul 17, 2023
It seems that we should do that, and actually pass the
-f
argument in the build script.fanasere commentedon Jul 18, 2023
that would greatly help us
thank you
adamsitnik commentedon Jul 18, 2023
I don't remember why exactly, but we have avoided that in the past (I know it sounds silly, but this code is now very old ;) ).
We should rather get
Directory.Build.Props
settings ignored, as they often cause issues (like enforcing treating warning as errors and getting errors when building the generated code). We have tried that, but it does not always work:BenchmarkDotNet/src/BenchmarkDotNet/Templates/CsProj.txt
Lines 4 to 5 in fd2639f
fanasere commentedon Jul 18, 2023
Yes I noticed these configurations but in my case they are not helping,
what does make it work is changing the configuration TargetFramework to TargetFrameworks at line 7.
as TargetFrameworks is a configuration that takes precedence over TargetFramework, and when comes from Directory.Build.Props it overrides the TargetFramework configuration in the generated csproj and causes this problem.
is there a downside to changing the configuration to TargetFrameworks?
timcassell commentedon Jul 18, 2023
Well, if we're going to be copying the entire original xproj in #1403, we will need to handle that case anyway. And hopefully that will also allow us to remove hacks like
<ImportDirectoryBuildProps>false</ImportDirectoryBuildProps>
.ShaharPrishMSFT commentedon Nov 16, 2023
The ImportDirectoryBuildProps is being ignored.. :\
How do I fix that?
adamsitnik commentedon Nov 16, 2023
@ViktorHofer @eerhardt @ericstj BDN generates a
.csproj
file where we try to ignore global prop files (hat often alter some MSBuild properites) by usingImportDirectoryBuildProps
tag. Is there something better that we can do to get them always ignored?BenchmarkDotNet/src/BenchmarkDotNet/Templates/CsProj.txt
Lines 1 to 6 in fc7afed
ShaharPrishMSFT commentedon Nov 16, 2023
I could not make those properties affect the build - it would always look at my .props file
What I ended up doing is have an empty Directory.Build.props file in my benchmark project (under a folder), and I copy it to the output folder.
This seems to solve the issue.
adamsitnik commentedon Nov 16, 2023
@ShaharPrishMSFT thanks for sharing the workaround!
ViktorHofer commentedon Nov 16, 2023
We usually do this the following way: https://github.com/dotnet/arcade/blob/main/src/Microsoft.DotNet.Arcade.Sdk/tools/Directory.Build.props
So, just create a Directory.Build.props file next to the project file with that content. Setting
ImportDirectoryBuildProps
to false in the project body is too late.ImportDirectoryBuildProps
not working inBenchmarkDotNet.Autogenerated.csproj
#2722 as a duplicate of this issue