Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
fanasere opened this issue Jul 16, 2023 · 10 comments · May be fixed by #2467
Open

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

fanasere opened this issue Jul 16, 2023 · 10 comments · May be fixed by #2467

Comments

@fanasere
Copy link

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
Copy link
Collaborator

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

@fanasere
Copy link
Author

that would greatly help us
thank you

@adamsitnik
Copy link
Member

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:

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

@fanasere
Copy link
Author

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
Copy link
Collaborator

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
Copy link

The ImportDirectoryBuildProps is being ignored.. :\

How do I fix that?

@adamsitnik
Copy link
Member

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?

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

@ShaharPrishMSFT
Copy link

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
Copy link
Member

@ShaharPrishMSFT thanks for sharing the workaround!

@ViktorHofer
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants