JFrog CLI dotnet test is adding an invalid argument

[santhoshjfrog]

Describe the bug

When running the jf dotnet test command, it is adding a --configfile argument that is not valid and causing a failure. Using the dotnet sdk 6.0 version.

Current behavior

Output: jf dotnet test --build-name santhosh --build-number 1.0.0 test.csproj 00:29:17 [🔵Info] Running dotnet... MSBUILD : error MSB1001: Unknown switch. Full command line: '/usr/share/dotnet/sdk/6.0.404/MSBuild.dll -maxcpucount -verbosity:m -restore -target:VSTest -nodereuse:false -nologo test.csproj --configfile /tmp/jfrog.cli.temp.-1673051357-1391855775/jfrog.cli.nuget.1635713996 -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,/usr/share/dotnet/sdk/6.0.404/dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,/usr/share/dotnet/sdk/6.0.404/dotnet.dll' Switches appended by response files: Switch: --configfile

For switch syntax, type "MSBuild -help" 00:29:18 [🚨Error] exit status 1

Reproduction steps

1. Install dotnet 6.0 version using the below commands on debian 11: apt install wget wget https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb sudo dpkg -i packages-microsoft-prod.deb sudo apt-get update sudo apt-get install -y dotnet-sdk-6.0

   2. Install latest version of JFrog CLI i.e 2.32.0 using below command: curl -fL https://install-cli.jfrog.io | sh

   3. Add the configuration using jf config add: Choose a server ID: JFrog Platform URL: https://.jfrog.io/ JFrog username: test
      JFrog password or API key: Is the Artifactory reverse proxy configured to accept a client certificate? (y/n) [n]? n

2. Configure jfrog CLI with dotnet using "jf dotnet-config" command: Resolve dependencies from Artifactory? (y/n) [y]? y Set Artifactory server ID: Set repository for dependencies resolution (press Tab for options): test-nuget Use NuGet V2 Protocol? (y/n) [n]? n 23:55:32 [🔵Info] dotnet build config successfully created.

3. Run jf dotnet --build-name build-name --build-number 1.0.0 test test.csproj command: 01:01:05 [🔵Info] Running dotnet... MSBUILD : error MSB1001: Unknown switch. Full command line: '/usr/share/dotnet/sdk/6.0.404/MSBuild.dll -maxcpucount -verbosity:m -restore -target:VSTest -nodereuse:false -nologo test.csproj --configfile /tmp/jfrog.cli.temp.-1673053265-235866294/jfrog.cli.nuget.3465337966 -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,/usr/share/dotnet/sdk/6.0.404/dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,/usr/share/dotnet/sdk/6.0.404/dotnet.dll' Switches appended by response files: Switch: --configfile

For switch syntax, type "MSBuild -help" 01:01:06 [🚨Error] exit status 1

The test.csproj file contains `

netcoreapp3.1 true

`

If we run jf dotnet --build-name build-name --build-number 1.0.0 restore test.csproj it is working without any issues:

01:01:15 [🔵Info] Running dotnet... Determining projects to restore... Restored /home/name/project-examples-master/nuget-example/test.csproj (in 477 ms). 01:01:17 [🔵Info] dotnet finished successfully.

So the issue is seen only with jf dotnet test command.

When we don't use jfrog CLI, we are not seeing any issues:

dotnet test test.csproj

Determining projects to restore... Restored /home/name/project-examples-master/nuget-example/test.csproj (in 4.42 sec).

Expected behavior

The jf dotnet test command should run with the passed arguments, not to rewrite it to msbuild with everything after it.

JFrog CLI version

2.32.0

Operating system type and version

debian 11

JFrog Artifactory version

No response

JFrog Xray version

No response

[ecooke-macu]

Any update on this?

[PM-JoakimGustavsson]

This bug is not unique to jfrog-cli, but also affects the Jenkins Artifactory Plugin. It can be recreated in a scripted Jenkins pipeline in a similar fashion as described by @santhoshjfrog . It seems to be an issue with the JFrog build-info layer. The argument is declared here:

https://github.com/jfrog/build-info/blob/67cefb286471634b88e104efe2543ad088010471/build-info-extractor-nuget/src/main/java/org/jfrog/build/extractor/nuget/drivers/ToolchainDriverBase.java#L22

And gets injected here:

https://github.com/jfrog/build-info/blob/642ee6a81fbce07cdc1ca954ca7686ff6495bd48/build-info-extractor-nuget/src/main/java/org/jfrog/build/extractor/nuget/extractor/NugetRun.java#L190-L200

So far I have used a commandline comment as a workaround for the issue. In Jenkins, running on a Windows-agent, meaning that the CLI shell will be bat, I can add a &REM at the end of the arguments I pass to the command. For example

rtBuild.run buildInfo: buildInfo, args: 'test &REM'

This comments out the injected arguments when they get passed to MSBuild. I assume adding a # would achieve a similar result with a Unix-shell. It is not in any way elegant, but it is effective as a temporary workaround.

[RobiNino]

Hi @santhoshjfrog , @edwardcookemacu , @PM-JoakimGustavsson , A fix for this issue was introduced in https://github.com/jfrog/jfrog-cli-core/pull/712 and is included in version 2.36.0 of JFrog CLI. Note that now a preceding restore is expected prior to a dotnet test command. The no-restore flag will be added to the command to avoid unintentional restore from a registry that is not the server configured in JFrog CLI's configuration.

We'd appreciate your feedback for the solution, thanks!

[ecooke-macu]

In my opinion changing the command is something that lead to this issue in the first place. It would also be something unexpected to happen for newcomers to the JFrog CLI. I would have expected jf dotnet test to behave identical to dotnet test. It's not an issue for us since we always do a build before the test, with a dedicated restore step, but I could see it causing problems for others.