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

Does BenchMarkDotnet supports 4.7.1 Dotnet framework #667

Closed
srikanthkadem opened this issue Feb 27, 2018 · 7 comments
Closed

Does BenchMarkDotnet supports 4.7.1 Dotnet framework #667

srikanthkadem opened this issue Feb 27, 2018 · 7 comments
Assignees
Milestone

Comments

@srikanthkadem
Copy link

Hi ,
Could you please confirm if the BenchMarkDotnet package support the latest dotnet framework i.e 4.7.1 . I was facing below runtime issue while trying to use this for projects targetted for 4.7.1

error
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
at BenchmarkDotNet.Running.BenchmarkConverter.GetParameterDefinitions(Type type)
at BenchmarkDotNet.Running.BenchmarkConverter.MethodsToBenchmarksWithFullConfig(Type containingType, MethodInfo[] benchmarkMethods, ReadOnlyConfig fullConfig)
at BenchmarkDotNet.Running.BenchmarkConverter.TypeToBenchmarks(Type type, IConfig config)
at BenchmarkDotNet.Running.BenchmarkRunner.Run[T](IConfig config)

@adamsitnik
Copy link
Member

Hi @srikanthkadem

which version of BenchmarkDotNet are you using? #621 was supposed to fix such problems, it was part of 0.10.12

If you are already using 0.10.12 then please provide me your .csproj file and sample benchmark (I need to be able to reproduce the problem)

@adamsitnik adamsitnik self-assigned this Feb 27, 2018
@kevin-montrose
Copy link

I've been updating my LinqAF project to target 4.7.1, and am now experiencing something quite similar though with System.Runtime.

My solution is gigantic, so I cut it down to a smaller Reproduction Solution; the relevant project is LinqAF.Benchmark. I apologize for the benchmarked project (LinqAF.Generated) still being quite large, but it's pretty hard to cut down. You'll need to restore NuGet packages.

Running the LinqAF.Benchmark will crash with a null ref 'cause nothing was actually benchmarked.

image
^ is the relevant output

@adamsitnik
Copy link
Member

Hi @kevin-montrose

Big thanks for the repro case.

I was able to reproduce your problem.

It looks that your assembly binding redirects are wrong. I am not sure if VS generated wrong ones for you during the target framework update or BDN installation. My VS complained about them:

image

Solution: remove all the assembly binding redirects.
If you need them please remove them, uninstall BDN and install it once again. I hope that VS will generate the right ones.

@adamsitnik
Copy link
Member

@kevin-montrose please let me know if it works after applying the "fix"

@kevin-montrose
Copy link

Yep, that looks to have been it. Have tested with my original solution, and the problem is fixed there as well. A little odd that my VS (2017 Professional, 4.7.02558 in case anyone else sees this) wasn't warning on that... but I doubt that's anything to do with BenchmarkDotNet.

Sorry for the delay in testing, my last two days have been jam packed.

Thanks a bunch!

@adamsitnik
Copy link
Member

@kevin-montrose thanks for the confirmation! I am happy it's not our fault ;)

@srikanthkadem has never responded so I am closing the issue.

adamsitnik added a commit that referenced this issue Feb 1, 2019
…ding redirect issues, fixes #942, fixes #896, fixes #895, fixes #667

* target .NET Standard 2.0 only

* don't box ;)

* use DirtyAssemblyResolveHelper in the auto-generated code because it's simply very common case that VS generates wrong redirects..

* disable two tests which fail due to CommandLineParser issue...

* bring Full .NET Framework tests back to life!

* make it possible to build BDN from source on Mac

* there is no way to do tell dotnet restore which configuration to use, we need to handle that for custom build configurations

* perform full build when user provided custom build configuration

* workaround bad assembly binding redirects on our side to keep the users happy ;)
@adamsitnik
Copy link
Member

This was one big PITA, fixed by using some ugly workarounds in #1032

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

No branches or pull requests

3 participants