Benchmarkdotnet: Benchmark fails to run when AssemblyName is different from csproj name on netcoreapp1.1 project

Created on 21 Jul 2017  路  8Comments  路  Source: dotnet/BenchmarkDotNet

Following guide from here
http://benchmarkdotnet.org/Overview.htm

Create a new project named ConsoleApp1 targeting netcoreapp1.1
Follow tutorial above to add benchmarks to it. All works fine when you run it.
Now modify csproj to have following (Notice AssemblyName attribute having different name than csproj (ConsoleApp1.csproj)

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <AssemblyName>Benchmarks</AssemblyName>
  </PropertyGroup>

dotnet run fails with

 Exception: System.NotSupportedException: Unable to find Benchmarks in C:\Users\smpatel\Source\Repos\ConsoleApp1 and its subfolders. Most probably the name of output exe is different than the name of the .(c/f)sproj
   at BenchmarkDotNet.Toolchains.CsProj.CsProjGenerator.GetProjectFilePath(Type benchmarkTarget, ILogger logger)
   at BenchmarkDotNet.Toolchains.CsProj.CsProjGenerator.GenerateProject(Benchmark benchmark, ArtifactsPaths artifactsPaths, IResolver resolver, ILogger logger)
   at BenchmarkDotNet.Toolchains.GeneratorBase.GenerateProject(Benchmark benchmark, ILogger logger, String rootArtifactsFolderPath, IConfig config, IResolver resolver)

Same thing works fine with net461 as tfm.

The executable created for net461 is named ConsoleApp.exe
The dll created for netcoreapp1.1 is named Benchmarks.dll

question

Most helpful comment

Hello @Mike-EEE !

BDN generates a new project, with reference to the .csproj file which defines the benchmarks.
\
So to run the benchmarks on the other machine you also need to copy the code ;)

If you don't/can't do that they you can use our [InProcessToolchain] (docs) which does everything inside the same process.

All 8 comments

@adamsitnik, could you take a look?

Hi!

This is by design, as you can see we have even a dedicated message for that:

Most probably the name of output exe is different than the name of the .(c/f)sproj

Why is that? We need to somehow find the csproj file that we want to reference. At the time of benchmark execution we know only the name of the assembly that defines benchmarks. This is why we search for csproj/fsproj with exact same name. If it's not found, we display the error message you got.

It's not a problem for .NET 4.6 because we are using Roslyn to compile for it, so we don't generate any csproj. For .NET Core we do.

My suggestion is that you should just rename the whole .csproj and don't use <AssemblyName> attribute for the project that defines benchmarks.

I am going to close the issue right now, please feel free to reopen it if you have better idea for finding the csproj.

@adamsitnik - That's what I suspected. Thanks for info.

Hi All... I am getting this message on a machine I am attempting to deploy a .NET Core 2.0 application to. When I run this locally on my development machine (out of the PublishOutput directory), this works like a champ. However, when I copy the directory in full to another machine (with .NET Core SDK and Runtime 2.0 installed), I get this message. Perplexed. :) Thank you for any assistance/insight you can lend that could be causing this error.

Hello @Mike-EEE !

BDN generates a new project, with reference to the .csproj file which defines the benchmarks.
\
So to run the benchmarks on the other machine you also need to copy the code ;)

If you don't/can't do that they you can use our [InProcessToolchain] (docs) which does everything inside the same process.

WOOHOO! Thank you @adamsitnik!!! My Hero. 馃槃 The InProcess did the trick.

BTW... have been taking some time away and obviously checked out BDN again. REALLY AMAZING! That DisassemblyDiagnoser article you wrote, Adam, is still leaving me floored. So much to digest!

But I have been really impressed with the little things too like the new legends and whatnot when results get printed. And speaking of which, the nice warning now for VM's is a great touch. This is the reason why I am trying to get this on another machine. 馃槈 Anyways, really great job here, team, and thanks again. 馃憤

thank you for the kind words!

You also need to check the histograms implemented by @AndreyAkinshin in 0.10.14. This feature rocks!

Yeah I was noticing that earlier this morning, VERY cool. Also admiring how you have gone about implementing different concepts in general. You have got to be in my top tier now of development heroes. Not just in your design approach but what you have done for the community as a whole. I think everyone is starting to gain more appreciation/awareness around performance and all the issues that involve this problem space. Lots of awesome going on here.

Was this page helpful?
0 / 5 - 0 ratings