Nbench: dotnet-nbench pode acidentalmente tentar executar [assembly-name] .deps.json em vez do assembly

Existe uma solução alternativa / alternativa por enquanto?

Tentei mudar o alvo do projeto, mas percebi que o problema era realmente com a CLI. Comecei a trabalhar por:
1) alterar a versão do CLI para esse projeto adicionando um global.json (ref: https://markheath.net/post/switching-between-netcore-sdk-versions)

2) Eu então tive um erro sobre não ter 2.1 para uma estrutura que exigia adicionar isso ao arquivo csproj no PropertyGroup:
2.1.6

3) Em seguida, ocorreu um erro sobre os pacotes restaurados com tempo de execução diferente de construir / publicar. A solução para isso era apenas executar "dotnet restore" do cli novamente.

Depois disso, consegui rodar "dotnet nbench" naquele projeto.

Obrigado por postar a solução alternativa detalhada! @izavala e eu estamos pensando em fazer outra grande revisão de usabilidade para o NBench 2.0 e isso estará em nossa lista para isso.

Apenas no caso de alguém se deparar com isso, mas como eu não posso mexer com as estruturas de destino ou global.json , outra solução alternativa é usar a bandeira --fx-version {version} com dotnet nbench , por exemplo:

fxversion=$(dotnet --list-runtimes | \
    grep Microsoft.NETCore.App | \
    awk '{ print $2 }' | \
    tail -1)

dotnet nbench --fx-version $fxversion

Ou:

$fxversion = dotnet --list-runtimes | `
    select-string "Microsoft.NETCore.App" | `
    select-object -last 1 | `
    foreach-object { $data = $_ -split " "; $data[1] }

dotnet nbench --fx-version $fxversion

O motivo da falha do comando sem isso é que o executor formata um comando dotnet exec com a variável fxVersion e, quando está vazio, resulta em --fx-version --depsfile "Foo.deps.json" . Este, por sua vez, é analisado por dotnet exec como se --depsfile fosse o valor da sinalização --fx-version , e o seguinte Foo.deps.json é interpretado como o arquivo de montagem a ser executado .

A linha ofensiva: https://github.com/petabridge/NBench/blob/557f2fbca250a4a45636f5e4b41b58b8440b33f2/src/NBench.Runner.DotNetCli/Program.cs#L284

Este patch deve corrigir isso, mas não tenho tempo para fazer o teste adequado e / ou uma solicitação de pull agora:

diff --git a/src/NBench.Runner.DotNetCli/Program.cs b/src/NBench.Runner.DotNetCli/Program.cs
index c45b32e..417319c 100644
--- a/src/NBench.Runner.DotNetCli/Program.cs
+++ b/src/NBench.Runner.DotNetCli/Program.cs
@@ -281,7 +281,10 @@ namespace NBench.Runner.DotNetCli
             var depsFile = targetFileNameWithoutExtension + ".deps.json";
             var runtimeConfigJson = targetFileNameWithoutExtension + ".runtimeconfig.json";

-            var args = $@"exec --fx-version {fxVersion} --depsfile ""{depsFile}"" ";
+            var args = $@"exec --depsfile ""{depsFile}"" ";
+
+            if (!string.IsNullOrWhiteSpace(fxVersion))
+                args += $"--fx-version {fxVersion} ";

             if (File.Exists(Path.Combine(workingDirectory, runtimeConfigJson)))
                 args += $@"--runtimeconfig ""{runtimeConfigJson}"" ";

Resolvido via NBench 2.0.0 https://github.com/petabridge/NBench/releases/tag/2.0.0 - não mais dotnet nbench .