Generated benchmarks ignore --framework flag when running out of process

[fanasere]

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

[timcassell]

It seems that we should do that, and actually pass the -f argument in the build script.

[fanasere]

that would greatly help us
thank you

[adamsitnik]

It seems that we should do that, and actually pass the -f argument in the build script.

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

	<ImportDirectoryBuildProps>false</ImportDirectoryBuildProps>
	<ImportDirectoryBuildTargets>false</ImportDirectoryBuildTargets>

[fanasere]

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]

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 ;) ).

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]

The ImportDirectoryBuildProps is being ignored.. :\

How do I fix that?

[adamsitnik]

How do I fix that?

@ViktorHofer @eerhardt @ericstj BDN generates a .csproj file where we try to ignore global prop files (hat often alter some MSBuild properites) by using ImportDirectoryBuildProps 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

	<Project Sdk="$SDKNAME$">
	<PropertyGroup>
	<ImportDirectoryBuildProps>false</ImportDirectoryBuildProps>
	<ImportDirectoryBuildTargets>false</ImportDirectoryBuildTargets>
	<AssemblyTitle>$PROGRAMNAME$</AssemblyTitle>

[ShaharPrishMSFT]

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]

@ShaharPrishMSFT thanks for sharing the workaround!

[ViktorHofer]

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.