vstest icon indicating copy to clipboard operation
vstest copied to clipboard

Incorrect transformation of command line args with `\` symbol on unix

Open nvborisenko opened this issue 7 months ago • 5 comments

On Windows the following command works good:

dotnet test -- NUnit.Where="namespace =~ /Abc\.Space1($|\.)/"

On Unix I use:

dotnet test -- NUnit.Where='namespace =~ /Abc\.Space1($|\.)/'

Error:

An exception occurred while invoking executor 'executor://nunit3testexecutor/': Unexpected token '.Space1($|' at position 18 in selection expression.

Gather diagnostics, and saw it:

TpTrace Information: 0 : 52885, 1, 2025/04/04, 17:51:29.669, 11794136606425, vstest.console.dll, TestRunRequest.ExecuteAsync: Starting run with settings:TestRunCriteria:
   KeepAlive=False,FrequencyOfRunStatsChangeEvent=10,RunStatsChangeEventTimeout=00:00:01.5000000,TestCaseFilter=,TestExecutorLauncher=
   Settingsxml=<RunSettings>
  <RunConfiguration>
    <ResultsDirectory>/mnt/e/Temp/Abc/TestResults</ResultsDirectory>
    <TargetPlatform>X64</TargetPlatform>
    <TargetFrameworkVersion>.NETCoreApp,Version=v8.0</TargetFrameworkVersion>
    <TestAdaptersPaths>/home/nick/.nuget/packages/coverlet.collector/6.0.4/build/netstandard2.0/</TestAdaptersPaths>
    <DesignMode>False</DesignMode>
    <CollectSourceInformation>False</CollectSourceInformation>
  </RunConfiguration>
  <NUnit>
    <Where>namespace =~ /Abc//.Space1($|//.)/</Where>
  </NUnit>
  <LoggerRunSettings>
    <Loggers>
      <Logger friendlyName="Console" uri="logger://microsoft/TestPlatform/ConsoleLogger/v1" assemblyQualifiedName="Microsoft.VisualStudio.TestPlatform.CommandLine.Internal.ConsoleLogger, vstest.console, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" codeBase="/usr/lib/dotnet/sdk/8.0.110/vstest.console.dll" enabled="True" />
    </Loggers>
  </LoggerRunSettings>
</RunSettings>

Please pay attention that my \ symbol is silently converted to //. It happens on Unix only.

nvborisenko avatar Apr 04 '25 14:04 nvborisenko

I tried to quickly find it, but see no suspicious code.

Image

Arrives correct to the task, but then gets transformed. I don't see any property reassignment to this property.

binlog: msbuild.zip

@YuliiaKovalova do you have any tips why that transformation on the parameter would happen? all property values show the value correct, but the task is called with the incorrect value.

nohwnd avatar Apr 04 '25 16:04 nohwnd

Hi Everyone,

I don't have a quick answer here. Please attach project with repro code and we will take a look :)

YuliiaKovalova avatar Apr 07 '25 09:04 YuliiaKovalova

Abc.zip

Attached simple project. To reproduce:

dotnet test -- NUnit.Where='namespace =~ /Abc\.Space1($|\.)/'

nvborisenko avatar Apr 08 '25 08:04 nvborisenko

Hello! I took a look at this issue. MSBuild tries to normalize paths when called in Unix. Unfortunately, there is no mechanism to detect whether the value is a path that needs normalization or some other entity, which leads to this behavior. This normalization (and the difficulties it causes) is a known issue in MSBuild: https://github.com/dotnet/msbuild/issues/3468.

In this particular case, I believe the normalization occurs because, in your task VSTestTask2 you define string array public string[]? VSTestCLIRunSettings. String arrays correspond to items and when you pass a property VSTestCLIRunSettings there, items are created silently. And one of the places where the normalization happens is on project items creation.

There are potential workarounds for this issue:

  1. Try to use %5C instead of \ in the CLI. This seems to prevent normalization. As option, dotnet test can try to replace \ with %5C when needed.
  2. Change the type from string[] to string and parse the array from the string within the task itself. This should eliminate the normalization during item creation (at least it did in my test project with another custom task).

AR-May avatar Apr 30 '25 13:04 AR-May

Copilot use the solution 2. Change the type from string[] to string and parse the array from the string within the task itself. This should eliminate the normalization during item creation (at least it did in my test project with another custom task).

nohwnd avatar Jun 12 '25 13:06 nohwnd