vstest: [17.3.0] Testhost process exited with error: Cannot use file stream for [...\bin\Debug\net6.0\testhost.deps.json]: No such file or directory
Description
Testing fails with VSTest 17.3.0 in an Azure DevOps pipeline and produces the following errors:
[error]Testhost process exited with error: Cannot use file stream for [...\bin\Debug\net6.0\testhost.deps.json]: No such file or directory
[error]A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Program Files\dotnet'.
[error]Failed to run as a self-contained app.
[error] - The application was run as a self-contained app because '...\bin\Debug\net6.0\testhost.runtimeconfig.json' was not found.
[error] - If this should be a framework-dependent app, add the '...\bin\Debug\net6.0\testhost.runtimeconfig.json' file and specify the appropriate framework.
[error]. Please check the diagnostic logs for more information.
Downgrading the version to 17.2.0 passes successfully.
Steps to reproduce
- Set Azure DevOps pipeline to install the latest VsTest platform.
- Set Azure DevOps pipeline to run tests with the below settings:
Running tests using vstest.console.exe runner.
======================================================
Test selector : Test assemblies
Test filter criteria : null
Search folder : C:\..\..\_w\212\s
Action when minimum tests threshold not met : donothing
Minimum tests expected to be run: 0
Run in parallel : false
Run in isolation : false
Path to custom adapters : null
Other console options : null
Code coverage enabled : true
Diagnostics enabled : true
SystemVssConnection exists true
Run the tests locally using vstest.console.exe
========================================================
Source filter: **\*test*.dll,!**\obj\**,!**\<project name>.Tests\**
Expected behavior
Testing should succeed as it did previously with version 17.2.0.
Actual behavior
Testing fails with version 17.3.0 and the above errors.
Diagnostic logs
Environment
OS Name: Microsoft Windows Server 2019 Standard Version: 10.0.17763 Build 17763 Console Version: VsTest\17.3.0\x64\tools\net451\Common7\IDE\Extensions\TestPlatform\vstest.console.exe
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 38 (14 by maintainers)
It seems that your run includes a lot of dlls that don’t contain tests, and most of the error out, but it also tries to run tests from
testhost.dll, could you try changing the filter to follow your naming convention, so it only matches*Tests.dll?From:
Source filter: **\*test*.dll,!**\obj\**,!**\<Function App Project Name>.Tests\**To:Source filter: **\*Tests.dll,!**\obj\**,!**\<Function App Project Name>.Tests\**@nohwnd Implementing a breaking change in this manner is unacceptable regardless of whether it makes the behaviour more “correct” (for your value of “correct”) or not. I, and most affected developers, consider “correct” to be “our test run doesn’t arbitrarily break out of the blue when I perform a minor version upgrade of a NuGet package”.
You do NOT, EVER, release a breaking change without first communicating it to end-users. You do NOT, EVER, release a breaking change as a minor version.
The right way to implement a breaking change is to release a version of the package that causes a warning to be raised around said change, while at the same time releasing a blog post/other communication indicating the behaviour indicated by the warning is going to become the default in the next MAJOR (not minor) version of vstest (because it’s a breaking change), and then implementing said behaviour in said major version.
Roll back this change and follow the process I’ve outlined above, which is basic software engineering discipline for decades, and stop causing unnecessary problems for developers.
https://github.com/microsoft/vstest/issues/3937#issuecomment-1236725873
I am sorry to say but I will call its a very bad decision by the team. If you going to break lot of consumers then you should at least prior inform them.
I have updated to this,
and it worked like a charm but I don’t think its good idea from VsTest to break the running pipelines suddenly, thanks @nickyquinn and @nohwnd 😃
We have had the same problem in my team and changing the filter works OK, thank you @nohwnd 😃
This changed, .NET “Core” dlls were silently ignored if there was at least one .NET Framework dll in the mix. Which causes tests to be lost. https://github.com/microsoft/vstest/issues/3937#issuecomment-1236725873
@snakefoot We are going to publish a fix for 17.3.1 that should make the issue smaller, but it won’t completely go away, because we are no longer silently ignoring .NET dlls that are added to the test run together with .NET Framework assemblies.
Solution is to use appropriate filter that only selects your tested dlls, usually a the small one with bin\ in it should work.
@nohwnd its auto generated YAML by Azure DevOps.
Here are the VsTests logs.