[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 #3937
Comments
|
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 From: |
|
We have had the same problem in my team and changing the filter works OK, thank you @nohwnd :-) |
|
I have a repro. Working on a fix. |
|
openend #3939 with suggested filters to use while we are fixing it. |
|
My Azure Dev Pipelines suddenly stopped working this week (working since more than 1 years without any change). Here is glimpse of YAML, |
|
Have you tried the fix suggested by nohwnd? Worked for me... your output suggests the test filter is |
|
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 :) |
|
@iqb-dawn I don't think it is a good idea either. Are there just .NET Framework projects in your solution? |
|
@nohwnd I have multiple projects/applications so they have different pipelines in same Azure DevOps project. Interestingly, only .NET Core 5 pipeline broken. The .NET framework pipeline is using, Which is still working fine. But .NET Core 5 project with below line is broken for some reason, The .NET framework test project name is |
|
I think that is because you are forcing the platform by setting the |
|
Making fix for that in #3949 |
|
@iqb-dawn if possible please post logs from your test run on azure devops so I am not guessing why it is broken. (both working and non-working logs would be highly appreciated :) ) |
|
@nohwnd its auto generated YAML by Azure DevOps. Here are the VsTests logs. |
|
Ah good point, let me re-check where they output the platform. That is not needed for 17.3+ and was not necessary for previous runs either. |
|
Alerts also started for me this monday when building with Azure DevOps (Nothing changed besides it became monday): |
|
@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. |
|
Notice for the NLog-project then downgrade from 17.3 to 17.2 did not remove the errors. But retrying the build or various build-agents could give successful builds: |
|
The upgrade to 17.3.1 also gives failed builds without any real clue: |
|
Maybe the issue is VSTest 17.3.0 has now somehow become case-sensitive so the filter will not work: |
I have had the same problem and changing the filter works OK |
|
Had the same problem and just re-added VSTest@2 entry in pipeline via GUI. Be careful with vsVersion you choose, as I had other issue while selecting other than 'latest'. before: after |
The filter did not become case-sensitive. The issue is that the default filter In 17.3 this no longer happens, and so any .NET Core dll that is not runnable will fail the run. The solution is to use a filter that matches only your test dlls (e.g. Here are examples of the suggested filter to use: #3939 |
|
So I'm using: From: https://zimmergren.net/unable-to-find-deps-json-dotnet-azure-devops/ |
|
@nohwnd Will it give problems for VsTest if using multi-target for the unit-test library, and the output-folder then contains dlls from multiple frameworks: <TargetFrameworks>net461;netcoreapp3.1</TargetFrameworks>Where |
|
I understand this is caused by the default filter picking up dlls that it's not meant to and searching them for unit tests, but why is this suddenly a problem now? What changed? Have the default filters changed or is it the way it matches files? |
|
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've used the same filters for 2 years and suddenly the whole pipeline fails while all tests are passing.
This is a bad decision indeed. |
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. #3937 (comment) |
I mean I hear that, but breaking people without putting a whole set of docs on the task remains a bad decision. Filtering the reference assemblies is also seemingly necessary. |
|
@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. 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.
|
|
I did the filter and it was looking for only one dll. Till I am getting the same error ##[debug]Processed: ##vso[task.logissue type=error;]Failed to run as a self-contained app. ##[error] - The application was run as a self-contained app because 'D:\a\1\a<myProject>\bin\Debug\net5.0\testhost.runtimeconfig.json' was not found. My yml:
|
|
@a140614 I would try using the filter that is recommended here: #3939 (comment) and replace *Tests.dll with your project dlls name. The recommended filter: Your filter: This should correctly target just a single dll in your bin folder, and you don't need the |
|
@nohwnd Thanks, I have tried those as well. See the logs. Same issue A total of 2 test files matched the specified pattern. ##[error]A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'D:\a\1\a<myProjectName>\bin\Debug\net5.0'. ##[error]Failed to run as a self-contained app. ##[error] - The application was run as a self-contained app because 'D:\a\1\a<myProjectName>\bin\Debug\net5.0\testhost.runtimeconfig.json' was not found. ##[error] - If this should be a framework-dependent app, add the 'D:\a\1\a<myProjectName>\bin\Debug\net5.0\testhost.runtimeconfig.json' file and specify the appropriate framework. ##[error]. Please check the diagnostic logs for more information. ##[error]Unable to find D:\a\1\a<myProjectName>\bin\Debug\net5.0\ref<myProjectName>.deps.json. Make sure test project has a nuget reference of package "Microsoft.NET.Test.Sdk". ##[error]Test Run Aborted.` My local it is running using the the below cmd command |
Evangelink
added
bug
needs-triage
|
Hi Guys, I am facing the same issue as discussed above, but I am new to this, I am looking for where to downgrade VSTest. Can someone point me to the right place |
|
@omoomoniyi do you have an Azure Pipeline? If so, you probably want to change its - task: VSTest-sxs@2
inputs:
testSelector: 'testAssemblies'
testAssemblyVer2: |
**\*test*.dll
!**\*TestAdapter.dll
!**\*TestCentric*.dll
!**\*TestHost*.dll
!**\*TestPlatform*.dll
!**\obj\**
searchFolder: '$(System.DefaultWorkingDirectory)'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
displayName: Tests |
@chucker Yes, I have an Azure Pipeline, but the setting does not resolve the issue as I am still getting the error |
|
@omoomoniyi is there any naming pattern to your test assemblies? Like they always end with Tests? You should avoid the filter with Much better is a filter, or multiple filters that match your test naming convention, without any * before |
nohwnd
added
by-design
and removed
bug
needs-triage
|
The underlying issue of matching .net standard dlls was implemented, rest is by desing, we don't want to skip your dlls, please use the suggested specific filter here or in #3939, rather than the azure devops default. |
Description
Testing fails with VSTest 17.3.0 in an Azure DevOps pipeline and produces the following errors:
Downgrading the version to 17.2.0 passes successfully.
Steps to reproduce
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
VsTestLogs.txt
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
The text was updated successfully, but these errors were encountered: