Nbench: dotnet-nbench puede intentar ejecutar accidentalmente [nombre-ensamblaje] .deps.json en lugar del ensamblado

¿Existe alguna solución o alternativa por ahora?

Intenté cambiar el objetivo del proyecto, pero me di cuenta de que el problema estaba realmente en la CLI. Lo tengo funcionando por:
1) cambiar la versión de la CLI para ese proyecto agregando un global.json (ref: https://markheath.net/post/switching-between-netcore-sdk-versions)

2) luego tuve un error acerca de no tener 2.1 para un marco que requería agregar esto al archivo csproj en PropertyGroup:
2.1.6

3) Luego hubo un error sobre los paquetes restaurados con un tiempo de ejecución diferente al de compilación / publicación. La solución para eso fue simplemente ejecutar "dotnet restore" desde el cli nuevamente.

Después de eso, pude ejecutar "dotnet nbench" contra ese proyecto bien.

¡Gracias por publicar la solución detallada! @izavala y yo estamos buscando hacer otra gran revisión de usabilidad para NBench 2.0 y esto estará en nuestra lista para eso.

Por si alguien se encuentra con esto, pero como yo no puede violín con los marcos de destino o global.json , otra solución alternativa es utilizar los indocumentados --fx-version {version} , marca con dotnet nbench , por ejemplo:

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

dotnet nbench --fx-version $fxversion

O:

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

dotnet nbench --fx-version $fxversion

La razón por la que el comando falla sin esto es que el corredor formatea un comando dotnet exec con la variable fxVersion , y cuando está vacío, esto da como resultado --fx-version --depsfile "Foo.deps.json" . Esto, a su vez, es analizado por dotnet exec como si --depsfile fuera el valor de la bandera --fx-version , y el siguiente Foo.deps.json se interpreta como el archivo de ensamblaje para ejecutar .

La línea ofensiva: https://github.com/petabridge/NBench/blob/557f2fbca250a4a45636f5e4b41b58b8440b33f2/src/NBench.Runner.DotNetCli/Program.cs#L284

Este parche debería solucionarlo, pero no tengo tiempo para hacer las pruebas adecuadas y / o una solicitud de extracción en este momento:

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}"" ";

Resuelto a través de NBench 2.0.0 https://github.com/petabridge/NBench/releases/tag/2.0.0 - no más dotnet nbench .