TRX file cannot be correctly located in VsTest 16.7 in Azure DevOps Pipeline

[aDisplayName]

Description

Starting today, the VsTest 16.7.0 is available in Azure DevOps pipeline. We got an error message at the end of the VsTest step that it clamied TRX was not found when publishing the test.
It appears the VsTest was looking for trx file in \agent\_work\_temp\TestResults while it was actually saved to $(Common.TestResultsDirectory)

We were using VsTest 16.6.1 with the same pipeline this past Sunday without problem.

Script

Here is the part of our yml pipeline file:

- task: VisualStudioTestPlatformInstaller@1
  displayName: 'VsTest Platform Installer'
  inputs:
    versionSelector: latestStable

# To avoid vstest execution error, we need to split tests into group by framework version.
- task: VSTest@2
  displayName: 'VsTest - testAssemblies - .Net Framework'
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: |
      **\MyApp.UnitTest.dll
      !**\obj\**
    searchFolder: '$(System.DefaultWorkingDirectory)'
    vsTestVersion: 'toolsInstaller'
    codeCoverageEnabled: true
    pathtoCustomTestAdapters: '$(System.DefaultWorkingDirectory)/test/UnitTests/MyApp.UnitTest'
    otherConsoleOptions: '/ResultsDirectory:$(Common.TestResultsDirectory)'

Log

Here is the log output:

**************** Starting test execution *********************
C:\agent\_work\_tool\VsTest\16.7.0\x64\tools\net451\Common7\IDE\Extensions\TestPlatform\vstest.console.exe "@C:\agent\_work\_temp\tb3bjofmr20.tmp"
Microsoft (R) Test Execution Command Line Tool Version 16.7.0
Copyright (c) Microsoft Corporation.  All rights reserved.
vstest.console.exe "C:\agent\_work\31\s\test\UnitTests\MyApp.UnitTest\bin\x86\Release\MyApp.UnitTest.dll"
/Settings:"C:\agent\_work\_temp\5k2prh3hdf4.tmp.runsettings"
/Logger:"trx"
/TestAdapterPath:"C:\agent\_work\31\s\test\UnitTests\MyApp.UnitTest"
/ResultsDirectory:C:\agent\_work\31\TestResults
Starting test execution, please wait...
Microsoft (R) Coverage Collection Tool Version 16.0.30319.200


Copyright (c) Microsoft Corporation.  All rights reserved.




Results File: C:\agent\_work\31\TestResults\CMMMM038$_CMMMM038_2020-08-07_14_38_13.trx
Attachments:
  C:\agent\_work\31\TestResults\c52bfe34-15a7-4762-bbff-fbba29cac278\CMMMM038$_CMMMM038 2020-08-07 14_38_06.coverage
Test Run Successful.
Total tests: 5
     Passed: 5
 Total time: 9.0765 Seconds
Vstest.console.exe exited with code 0.
**************** Completed test execution *********************
Test results files: 
##[error]Error occurred while publishing test results : MS.VS.TestService.VstestConsoleAdapter.NoTrxFoundException: No trx files found in the specified test results directory C:\agent\_work\_temp\TestResults.
##[error]Skipping marking test run as complete as test run id 0 is invalid.
Completed TestExecution Model...
##[warning]Vstest failed with error. Check logs for failures. There might be failed tests.
##[error]Error: The process 'C:\agent\_work\_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\2.170.1\Modules\DTAExecutionHost.exe' failed with exit code 1
##[error]Vstest failed with error. Check logs for failures. There might be failed tests.
Finishing: VsTest - testAssemblies - .Net Framework

Here is the log output for VsTest 16.7.0 installation

==============================================================================
Task         : Visual Studio test platform installer
Description  : Acquire the test platform from nuget.org or the tool cache. Satisfies the ‘vstest’ demand and can be used for running tests and collecting diagnostic data using the Visual Studio Test task.
Version      : 1.151.3
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/tool/vstest-platform-tool-installer
==============================================================================
Starting VsTest platform tools installer task.
==============================================================================
Looking for the latest stable version of the Microsoft.Testplatform.
C:\agent\_work\_tasks\VisualStudioTestPlatformInstaller_2c65196a-54fd-4a02-9be8-d9d1837b7111\1.151.3\nuget.exe list packageid:Microsoft.TestPlatform -NonInteractive -Source https://api.nuget.org/v3/index.json
Microsoft.TestPlatform 16.7.0
C:\agent\_work\_tasks\VisualStudioTestPlatformInstaller_2c65196a-54fd-4a02-9be8-d9d1837b7111\1.151.3\nuget.exe install Microsoft.TestPlatform -Version 16.7.0 -Source https://api.nuget.org/v3/index.json -OutputDirectory C:\agent\_work\_temp\VsTest -NoCache -DirectDownload -NonInteractive
Feeds used:
  https://api.nuget.org/v3/index.json



Attempting to gather dependency information for package 'Microsoft.TestPlatform.16.7.0' with respect to project 'C:\agent\_work\_temp\VsTest', targeting 'Any,Version=v0.0'
Gathering dependency information took 1.26 sec
Attempting to resolve dependencies for package 'Microsoft.TestPlatform.16.7.0' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.TestPlatform.16.7.0'
Resolved actions to install package 'Microsoft.TestPlatform.16.7.0'
Retrieving package 'Microsoft.TestPlatform 16.7.0' from 'nuget.org'.
  GET https://api.nuget.org/v3-flatcontainer/microsoft.testplatform/16.7.0/microsoft.testplatform.16.7.0.nupkg
  OK https://api.nuget.org/v3-flatcontainer/microsoft.testplatform/16.7.0/microsoft.testplatform.16.7.0.nupkg 51ms
Adding package 'Microsoft.TestPlatform.16.7.0' to folder 'C:\agent\_work\_temp\VsTest'
Added package 'Microsoft.TestPlatform.16.7.0' to folder 'C:\agent\_work\_temp\VsTest'
Successfully installed 'Microsoft.TestPlatform 16.7.0' to C:\agent\_work\_temp\VsTest
Executing nuget actions took 7.53 sec
Caching tool: VsTest 16.7.0 x64
VsTest will use the Test Platform package found in C:\agent\_work\_tool\VsTest\16.7.0\x64

We were using VsTest 16.6.1 without problem before today.

Environment

The agent is running at Windows 10 1803

[Sanan07]

@aDisplayName Are you able to access this result file Results File: C:\agent\_work\31\TestResults\CMMMM038$_CMMMM038_2020-08-07_14_38_13.trx? As I know ,we have not done any changes related to TestResults directory in 16.7.0. We will try to look into it.

[Sanan07]

@aDisplayName I tested using VsTest 16.7.0 with specifying ResultsDirectory and it worked fine.

So, in your case trx file was saved to /ResultsDirectory:C:\agent\_work\31\TestResults as you specify it as argument, but AzDo were looking at it in $(Common.TestResultsDirectory) which has value C:\agent\_work\_temp\TestResults, that why it failed to find it there.

And this MS.VS.TestService.VstestConsoleAdapter.NoTrxFoundException: No trx files found in the specified test results directory looks like a AzDo exception. Maybe @ShreyasRmsft can also help us.

@aDisplayName Could you also provide runsettings file?

[aDisplayName]

Thanks @Sanan07

@aDisplayName Are you able to access this result file Results File: C:\agent\_work\31\TestResults\CMMMM038$_CMMMM038_2020-08-07_14_38_13.trx? As I know ,we have not done any changes related to TestResults directory in 16.7.0. We will try to look into it.

Yes, the trx, coverage, and the raw data were all under C:\agent_work\31 folder.
There is nonthing under C:\agent_work_temp\TestResults folder.

@aDisplayName I tested using VsTest 16.7.0 with specifying ResultsDirectory and it worked fine.

So, in your case trx file was saved to /ResultsDirectory:C:\agent\_work\31\TestResults as you specify it as argument, but AzDo were looking at it in $(Common.TestResultsDirectory) which has value C:\agent\_work\_temp\TestResults, that why it failed to find it there.

And this MS.VS.TestService.VstestConsoleAdapter.NoTrxFoundException: No trx files found in the specified test results directory looks like a AzDo exception. Maybe @ShreyasRmsft can also help us.

@aDisplayName Could you also provide runsettings file?

The only runsettings was the one generated by VsTest task. I've attached the full log here.
21.log

Also, the azure agent version is 2.165.0

[aDisplayName]

@Sanan07 , I agree with you. It seems VsConsole.exe did complete with exit code 0. And indeed it was the DTAExecutionHost.exe which exited with error code 1:

##[error]Error: The process 'C:\agent\_work\_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\2.170.1\Modules\DTAExecutionHost.exe' failed with exit code 1

[Sanan07]

@aDisplayName Please look at this #11526 and https://developercommunity.visualstudio.com/content/problem/756960/21574modulesdtaexecutionhostexe-failed-with-exit-c.html
As I understood by default AzDo writes results in temp folder, but you can overwrite it. But in your case it still looks at temp folder, instead of looking at the folder which you specify as an argument. Try to run again an agent and see if you get the same behaviour.

[aDisplayName]

@Sanan07 But the only thing between pass and fail is the change from VsTest 16.6.1 to 16.7.0.

Actually I tried with 16.6.1 today after we had problem with 16.7.0, and the tasks passed without any glitch. Back to 16.7.0, failed again. Same build agent.

[Sanan07]

@aDisplayName Could you please provide installation logs for VsTest 16.6.1 as you provided in your post for 16.7.0?

As you may see above 16.7.0 was installed inside work\temp folder, probably that is why it tries to reach trx log file from there :

Adding package 'Microsoft.TestPlatform.16.7.0' to folder 'C:\agent\_work\_temp\VsTest' Added package 'Microsoft.TestPlatform.16.7.0' to folder 'C:\agent\_work\_temp\VsTest' Successfully installed 'Microsoft.TestPlatform 16.7.0' to C:\agent\_work\_temp\VsTest Executing nuget actions took 7.53 sec Caching tool: VsTest 16.7.0 x64 VsTest will use the Test Platform package found in C:\agent\_work\_tool\VsTest\16.7.0\x64

[aDisplayName]

@Sanan07 as far as I know, every azure task is using _work\_temp during installation

[aDisplayName]

@Sanan07, I am able to reproduce the problem with the following azure pipeline scripts.
Two yml scripts are provided: One for vstest 16.6.1, and the other one for 16.7.0. You should be able to reprodue the problem using the windows-latest vmImage from Azure Hosted Agent. No other code is required.

Using vstest 16.6.1

When using vstest 16.6.1, all task completed without problem

trigger: none

pool:
  vmImage: 'windows-latest'

workspace:
  clean: all

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk 3.1.302'
  inputs:
    version: 3.1.302

- powershell: |
    Set-Location $(System.DefaultWorkingDirectory)
    dotnet new mstest -o MyApp.UnitTest
    dotnet build MyApp.UnitTest/MyApp.UnitTest.csproj -o output
  
  
- task: VisualStudioTestPlatformInstaller@1
  displayName: 'VsTest Platform Installer'
  inputs:
    packageFeedSelector: 'nugetOrg'
    versionSelector: 'specificVersion'
    testPlatformVersion: '16.6.1'

- task: VSTest@2
  displayName: 'VsTest - testAssemblies - .Net Framework'
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: |
      **/MyApp.UnitTest.dll
    searchFolder: '$(System.DefaultWorkingDirectory)/output'
    vsTestVersion: 'toolsInstaller'
    codeCoverageEnabled: true
    pathtoCustomTestAdapters: '$(System.DefaultWorkingDirectory)/output'
    otherConsoleOptions: '/ResultsDirectory:$(Common.TestResultsDirectory)'

- task: PublishTestResults@2
  displayName: 'Publish Test Results'
  inputs:
   testResultsFormat: 'VSTest'
   testResultsFiles: '$(Common.TestResultsDirectory)/**/*.trx'

Using vstest 16.7.0

When using vstest 16.7.0, the vstest task failed when publishing the test result.

trigger: none

pool:
  vmImage: 'windows-latest'

workspace:
  clean: all

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk 3.1.302'
  inputs:
    version: 3.1.302

- powershell: |
    Set-Location $(System.DefaultWorkingDirectory)
    dotnet new mstest -o MyApp.UnitTest
    dotnet build MyApp.UnitTest/MyApp.UnitTest.csproj -o output
  
  
- task: VisualStudioTestPlatformInstaller@1
  displayName: 'VsTest Platform Installer'
  inputs:
    packageFeedSelector: 'nugetOrg'
    versionSelector: 'specificVersion'
    testPlatformVersion: '16.7.0'

# To avoid vstest execution error, we need to split tests into group by framework version.
- task: VSTest@2
  displayName: 'VsTest - testAssemblies - .Net Framework'
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: |
      **/MyApp.UnitTest.dll
    searchFolder: '$(System.DefaultWorkingDirectory)/output'
    vsTestVersion: 'toolsInstaller'
    codeCoverageEnabled: true
    pathtoCustomTestAdapters: '$(System.DefaultWorkingDirectory)/output'
    otherConsoleOptions: '/ResultsDirectory:$(Common.TestResultsDirectory)'

- task: PublishTestResults@2
  displayName: 'Publish Test Results'
  inputs:
   testResultsFormat: 'VSTest'
   testResultsFiles: '$(Common.TestResultsDirectory)/**/*.trx'

Here is the build agent information

2020-08-08T03:14:52.4713503Z ##[section]Starting: Initialize job
2020-08-08T03:14:52.4715025Z Agent name: 'Hosted Agent'
2020-08-08T03:14:52.4715363Z Agent machine name: 'fv-az674'
2020-08-08T03:14:52.4715579Z Current agent version: '2.173.0'
2020-08-08T03:14:52.4767213Z ##[group]Operating System
2020-08-08T03:14:52.4767497Z Microsoft Windows Server 2019
2020-08-08T03:14:52.4767652Z 10.0.17763
2020-08-08T03:14:52.4767782Z Datacenter
2020-08-08T03:14:52.4767933Z ##[endgroup]
2020-08-08T03:14:52.4768088Z ##[group]Virtual Environment
2020-08-08T03:14:52.4768270Z Environment: windows-2019
2020-08-08T03:14:52.4768443Z Version: 20200802.1
2020-08-08T03:14:52.4768749Z Included Software: https://github.com/actions/virtual-environments/blob/win19/20200802.1/images/win/Windows2019-Readme.md
2020-08-08T03:14:52.4769028Z ##[endgroup]
2020-08-08T03:14:52.4769869Z Current image version: '20200802.1'
2020-08-08T03:14:52.4775867Z Agent running as: 'VssAdministrator'
2020-08-08T03:14:52.4815061Z Prepare build directory.
2020-08-08T03:14:52.5078768Z Set build variables.
2020-08-08T03:14:52.5112160Z Download all required tasks.
2020-08-08T03:14:52.5225718Z Downloading task: UseDotNet (2.171.0)
2020-08-08T03:14:54.5404379Z Downloading task: PowerShell (2.170.1)
2020-08-08T03:14:54.8021028Z Downloading task: VisualStudioTestPlatformInstaller (1.151.3)
2020-08-08T03:14:55.1260638Z Downloading task: VSTest (2.170.1)
2020-08-08T03:14:56.7509719Z Downloading task: PublishTestResults (2.171.0)
2020-08-08T03:14:57.5531780Z Checking job knob settings.
2020-08-08T03:14:57.5540533Z    Knob: AgentToolsDirectory = C:/hostedtoolcache/windows Source: ${AGENT_TOOLSDIRECTORY} 
2020-08-08T03:14:57.5541884Z    Knob: AgentPerflog = c:\vsts\perflog Source: ${VSTS_AGENT_PERFLOG} 
2020-08-08T03:14:57.5542896Z Finished checking job knob settings.
2020-08-08T03:14:57.5868290Z Start tracking orphan processes.
2020-08-08T03:14:57.5921876Z ##[section]Finishing: Initialize job

[Sanan07]

@aDisplayName Could you run the agent with v16.7 but without this property otherConsoleOptions: '/ResultsDirectory:$(Common.TestResultsDirectory)' and see if AzDo can successfully get the trx file.

As from logs, again it looks like vstest completed successfully, but issue occurs when AzDo trying got fetch trx log file.
@ShreyasRmsft Could you please look at the issue?

[aDisplayName]

@aDisplayName Could you run the agent with v16.7 but without this property otherConsoleOptions: '/ResultsDirectory:$(Common.TestResultsDirectory)' and see if AzDo can successfully get the trx file.

@Sanan07 The answer is "Yes" that removing the /ResultsDirectory setting solved the problem. But that is not the solution we can take.

The long story of why we have to use '/ResultsDirectory:$(Common.TestResultsDirectory)':

• In our production build pipeline, we have multiple test projects, and we use SonarQube to calculate the overall test coverage.
• Some of those unit test projects are targetting .NET Framework, while the rest are targetting .NET Core.
• We had problem to run all tests within one VsTest tasks due to the difference of target framework, so we splitted them into two VsTest tasks targetting different framework.
• Without setting /ResultsDirectory to $(Common.TestResultsDirectory), the test result in temp folder from the first VsTest task will be cleared out by second VsTest task, which would then prevent SonarQube to collect both test coverage results for SonarQube Code Analysis task.
• The solution we've found, is to add '/ResultsDirectory:$(Common.TestResultsDirectory)' option to both VsTest tasks, so that the test results will be preserved after each test run, and be available for following SonarQube code run analysis task to consume.

That is the reason why we have to have /ResultsDirectory option set as it is shown in the sample code.

[ShreyasRmsft]

@aDisplayName are you using AzureDevOps onprem or AzureDevOps hosted service?
If onprem please mention which version.

[aDisplayName]

@ShreyasRmsft Azure DevOps hosted service. Sprint 172

[ShreyasRmsft]

@aDisplayName you'd need to use the dedicated input of results folder input field instead of providing it in the otherconsoleoptions input since we do not parse/validate otherconsole options as it is an open ended field and just pass it on to vstest.console.exe.

[aDisplayName]

@aDisplayName you'd need to use the dedicated input of results folder input field instead of providing it in the otherconsoleoptions input since we do not parse/validate otherconsole options as it is an open ended field and just pass it on to vstest.console.exe.

@Sanan07 , Will it be possible to tell why the change of VsTest version caused the behavior change in pipeline task?

@ShreyasRmsft Sorry, but your solution doesn't work for us.

Consider the following script, only the second vstest result is available for "Publish Test Results" task. Apparently the first vstest result was cleared up by resultsFolder: '$(Common.TestResultsDirectory)' option in the second vstest

As I've mentioned earlier, our "SonarQube" code analysis task needs test results from all vstest tasks to be available.

trigger: none

pool:
  vmImage: 'windows-latest'

workspace:
  clean: all

steps:
- task: UseDotNet@2
  displayName: 'Use .NET Core sdk 3.1.302'
  inputs:
    version: 3.1.302

- powershell: |
    Set-Location $(System.DefaultWorkingDirectory)
    dotnet new mstest -o MyApp.UnitTest
    dotnet build MyApp.UnitTest/MyApp.UnitTest.csproj -o output
    Write-Host hello
    Write-Host $(Common.TestResultsDirectory)
  
- task: VisualStudioTestPlatformInstaller@1
  displayName: 'VsTest Platform Installer'
  inputs:
    packageFeedSelector: 'nugetOrg'
    versionSelector: 'latestStable'

# To avoid vstest execution error, we need to split tests into group by framework version.
- task: VSTest@2
  displayName: 'VsTest - testAssemblies - .Net Framework'
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: '**/MyApp.UnitTest.dll'
    searchFolder: '$(System.DefaultWorkingDirectory)/output'
    resultsFolder: '$(Common.TestResultsDirectory)'
    vsTestVersion: 'toolsInstaller'
    pathtoCustomTestAdapters: '$(System.DefaultWorkingDirectory)/output'
    codeCoverageEnabled: true


- task: VSTest@2
  displayName: 'VsTest - testAssemblies - .Net Framework'
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: '**/MyApp.UnitTest.dll'
    searchFolder: '$(System.DefaultWorkingDirectory)/output'
    resultsFolder: '$(Common.TestResultsDirectory)'
    vsTestVersion: 'toolsInstaller'
    pathtoCustomTestAdapters: '$(System.DefaultWorkingDirectory)/output'
    codeCoverageEnabled: true

- powershell: |
    Get-ChildItem $(Common.TestResultsDirectory)/*.trx -Recurse | Write-Host
    Get-ChildItem $(Common.TestResultsDirectory)/*.trx -Recurse | Measure-Object
    
- task: PublishTestResults@2
  displayName: 'Publish Test Results'
  inputs:
   testResultsFormat: 'VSTest'
   testResultsFiles: '$(Common.TestResultsDirectory)/**/*.trx'

[ShreyasRmsft]

@aDisplayName Couple of points, the vstest task itself publishes the testresults for you. By adding another publish you are creating duplicate test runs/results on the server that will show up in the tests UI.

Today the vstest task instance always cleans up the test results folder at the beginning of a run to avoid conflicts. You can specify $(Common.TestResultsDirectory)/VstestTaskInstance1, $(Common.TestResultsDirectory)/VstestTaskInstance2 as the results directories for subsequent instances.

[aDisplayName]

@ShreyasRmsft @Sanan07 Thanks.

It is clear to me now. The conclusion is that there is a behavior changes from VsTest 16.6.1 to 16.7.0 that regarding test result publishing when running within VsTest Azure Pipeline Task.

Regards

[AmadeusW]

Our CI pipeline just started to fail with NoTrxFoundException: No trx files found in the specified test results directory C:\A\1\_temp\TestResults.

Excerpts from the log:
Setup:

##[debug]Agent.TempDirectory=C:\A\1\_temp
##[debug]resultsFolder=C:\A\1\_temp\TestResults
##[debug]TestResultsFolder: C:\A\1\_temp\TestResults
##[debug]Agent.TempDirectory=C:\A\1\_temp
##[debug]telemetry area: TestExecution feature: ResultsDirectory data: {"TestResultsFolderUi":"$(Agent.TempDirectory)/TestResults"}
##[debug]Processed: ##vso[telemetry.publish area=TestExecution;feature=ResultsDirectory;]{"TestResultsFolderUi":"$(Agent.TempDirectory)/TestResults"}
##[debug]System.PullRequest.TargetBranch=undefined
##[debug]vstest.ignoretestfailures=undefined
##[debug]BUILD_DEFINITIONNAME=VS-Platform-CI
##[debug]BUILD_BUILDNUMBER=16.9.194-preview+a5a3647460
##[debug]failOnMinTestsNotRun=False

More setup:

##[debug]Starting the ExecutionStateModel
##[debug]Current phase: MS.VS.TestService.VstestConsoleAdapter.SetupPhase
##[debug]SetupPhase.Run: Running necessary setup steps.
##[debug]Creating a dummy run settings file.
##[debug]Code coverage node not present.
##[debug]Updating the BatchSize in RunSettings to 1000
##[debug]Run configuration not found in the runsettings, so adding one with BatchSize
##[debug]Updating ResultDirectory by editing given runsettings if needed.
##[debug]UpdateIfRequiredAndParse called for TestResultsDirectoryRunsettingsParser.
##[debug]ResultsDirectory node not found in run configuration. So adding ResultsDirectory node.
##[debug]CommonSettingsManager : TestResultsDirectory intialized to C:\A\1\_temp\TestResults
Updated Run Settings:
<RunSettings>
  <RunConfiguration>
    <BatchSize>1000</BatchSize>
    <ResultsDirectory>C:\A\1\_temp\TestResults</ResultsDirectory>
  </RunConfiguration>
</RunSettings>

After test execution:

##[debug]Current Phase: MS.VS.TestService.VstestConsoleAdapter.ExecuteVsTestPhase Phase Result: MS.VS.TestService.VstestConsoleAdapter.ExecutionVsTestPhaseResults
##[debug]PERF WARNING: Running the phase MS.VS.TestService.VstestConsoleAdapter.ExecuteVsTestPhase: took 3599611.6543 ms
##[debug]Current phase: MS.VS.TestService.VstestConsoleAdapter.PublishTestResultPhase
##[debug]Starting Publish Test Results: TIA: False
##[debug]Starting PublishTestResult from Result Files
Test results files: 
##[debug]PERF: PublishTestResultPhase.Publish: took 3.0138 ms
##[debug]Completed Publish Test Results.
##[debug]Current Phase: MS.VS.TestService.VstestConsoleAdapter.PublishTestResultPhase Phase Result: MS.VS.TestService.VstestConsoleAdapter.PublishTestResultPhaseResults
##[error]Error occurred while publishing test results : MS.VS.TestService.VstestConsoleAdapter.NoTrxFoundException: No trx files found in the specified test results directory C:\A\1\_temp\TestResults.
##[debug]Processed: ##vso[task.logissue type=error;]Error occurred while publishing test results : MS.VS.TestService.VstestConsoleAdapter.NoTrxFoundException: No trx files found in the specified test results directory C:\A\1\_temp\TestResults.

@ShreyasRmsft how can we restore our ability to run tests?

[ChrisGuzak]

I am having a similar problem, but it only impacts the "release,x86" test run. For people with MS corp net access here is the log showing the failure.

[AmadeusW]

FYI our issue turned out to be a deadlocked test. After an hour, the test runner process was ended without producing the .trx file. What we really need here is

1. Azure task to report a message that test runner process was terminated due to timeout
2. The test runner to report that a test (provide a name) did not finish running, so that developer can immediately focus on that test.

[ChrisGuzak]

@AmadeusW thank you. in my case I had a buggy test that resulted in calling std::terminate(). it seems vstest does not consider that a test failure and it just times out. I'll look into filing a vstest bug.