Nbench: dotnet-nbench peut accidentellement essayer d'exécuter [assembly-name].deps.json au lieu de l'assembly

Créé le 22 janv. 2019  ·  5Commentaires  ·  Source: petabridge/NBench

Se produit sur les nœuds exécutant .NET Core 2.2 et versions ultérieures.

bug benchmark-execution netcore

Tous les 5 commentaires

Existe-t-il une solution de contournement/alternative pour le moment ?

J'ai essayé de changer la cible du projet, mais j'ai réalisé que le problème venait vraiment de la CLI. Je l'ai fait fonctionner par :
1) changer la version de la CLI pour ce projet en ajoutant un global.json (réf : https://markheath.net/post/switching-between-netcore-sdk-versions )

2) j'ai alors eu une erreur de ne pas avoir 2.1 pour un cadre qui nécessitait de l'ajouter au fichier csproj dans le PropertyGroup :
2.1.6

3) Ensuite, il y a eu une erreur sur les packages restaurés avec un runtime différent de celui de build/publish. Le correctif consistait simplement à exécuter à nouveau la "restauration dotnet" à partir de la CLI.

Après cela, j'ai pu exécuter correctement "dotnet nbench" sur ce projet.

Merci d'avoir publié la solution de contournement détaillée ! @izavala et moi envisageons de faire une autre refonte majeure de la convivialité de NBench 2.0 et ce sera sur notre liste pour cela.

Juste au cas où quelqu'un rencontre cela, mais comme moi ne peut pas jouer avec les frameworks cibles ou global.json , une autre solution consiste à utiliser le drapeau --fx-version {version} avec dotnet nbench , par exemple:

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

La raison pour laquelle la commande échoue sans cela est que le programme d'exécution formate une commande dotnet exec avec la variable fxVersion , et lorsqu'elle est vide, cela donne --fx-version --depsfile "Foo.deps.json" . Celui-ci est à son tour analysé par dotnet exec comme si --depsfile était la valeur de l'indicateur --fx-version , et le Foo.deps.json est interprété comme le fichier d'assemblage à exécuter .

La ligne incriminée : https://github.com/petabridge/NBench/blob/557f2fbca250a4a45636f5e4b41b58b8440b33f2/src/NBench.Runner.DotNetCli/Program.cs#L284

Ce patch devrait le corriger mais je n'ai pas le temps de faire des tests appropriés et/ou une pull request pour le moment :

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

Résolu via NBench 2.0.0 https://github.com/petabridge/NBench/releases/tag/2.0.0 - plus de dotnet nbench .

Cette page vous a été utile?
0 / 5 - 0 notes