runtime: The library 'hostpolicy.dll' required to execute the application was not found in

@robertborr @borysl I found the solution to “My” problem. Notice the following line contains **\*test*.dll This means that “Any” file that has test in the filename and is a dll will be used.

XUnit places a file called testhost.dll in the output directory, which matches the glob and is based on .netcore 1.x hence the need of the runner to attempt to use that as the runner policy for that test.dll

I changed the filer to be **\*test.dll (removed the last *) and now all is happy again; i.e. the first message is not displayed and th xunit runner still works as expected.

I’ve reproduced this issue when was running xunit tests with the project reference

I’ve reproduced this issue when was running xunit tests with the project reference

Same here via a azure-pipelines.yml file. Needing to run VSTest@2 due to needing to use rosyln against a .netcore 2.2 test dll that also performs runtime compile tests against output files. Here is the yml extract:

- task: VSTest@2
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: |
             **\*test*.dll
             !**\*TestAdapter.dll
             !**\obj\**
    runInParallel: true
    codeCoverageEnabled: true
    publishRunAttachments: true
    configuration: $(buildConfiguration)
#    runSettingsFile: 'Test.runsettings'
    testRunTitle: $(Agent.JobName)
    timeoutInMinutes: 20
    diagnosticsEnabled: true
    collectDumpOn: 'always'

I then get the following for each of the Test.dlls

##[error]Testhost process exited with error: A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'd:\a\1\s\Tests\CSharp.Tests\bin\Release\netcoreapp2.2\'.
##[error]Failed to run as a self-contained app. If this should be a framework-dependent app, add the d:\a\1\s\Tests\CSharp.Tests\bin\Release\netcoreapp2.2\testhost.runtimeconfig.json file specifying the appropriate framework.
##[error]. Please check the diagnostic logs for more information.

But the files still run against Xunit. (See the end) BUT, because of the errors, the VSTest action fails!

[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.1 (64-bit .NET Core 4.6.28008.02)
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.1 (64-bit .NET Core 4.6.28008.02)
[xUnit.net 00:00:06.55]   Discovering: 2CSharp.Tests
[xUnit.net 00:00:06.64]   Discovered:  CSharp.Tests
[xUnit.net 00:00:06.65]   Starting:    CSharp.Tests
[xUnit.net 00:00:07.27]   Finished:    CSharp.Tests


  √ LaTeX2CSharp.Tests.CSharpTests.A100_SimplePower [1ms]
  √ LaTeX2CSharp.Tests.CSharpTests.A050_SimpleRoot [1ms]
  ! LaTeX2CSharp.Tests.CSharpTests.A140_NumberInVarName [1ms]
etc.

I have the same issue as @canpolat . It started as soon one XUnit test project referenced another one. The issue occurs only in the Azure DevOps Pipeline. VS 2019 is able to run all tests.

I can confirm: Upgrading to Microsoft.NET.Test.SDK version 16.6.1 did not solve it.

At the moment I use a very dirty workaround to overcome this error. Is there a better solution than removing the reference to another XUnit test project?

I’ve reproduced this issue when was running xunit tests with the project reference

Same here via a azure-pipelines.yml file. Needing to run VSTest@2 due to needing to use rosyln against a .netcore 2.2 test dll that also performs runtime compile tests against output files. Here is the yml extract:

- task: VSTest@2
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: |
             **\*test*.dll
             !**\*TestAdapter.dll
             !**\obj\**
    runInParallel: true
    codeCoverageEnabled: true
    publishRunAttachments: true
    configuration: $(buildConfiguration)
#    runSettingsFile: 'Test.runsettings'
    testRunTitle: $(Agent.JobName)
    timeoutInMinutes: 20
    diagnosticsEnabled: true
    collectDumpOn: 'always'

I then get the following for each of the Test.dlls

##[error]Testhost process exited with error: A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'd:\a\1\s\Tests\CSharp.Tests\bin\Release\netcoreapp2.2\'.
##[error]Failed to run as a self-contained app. If this should be a framework-dependent app, add the d:\a\1\s\Tests\CSharp.Tests\bin\Release\netcoreapp2.2\testhost.runtimeconfig.json file specifying the appropriate framework.
##[error]. Please check the diagnostic logs for more information.

But the files still run against Xunit. (See the end) BUT, because of the errors, the VSTest action fails!

[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.1 (64-bit .NET Core 4.6.28008.02)
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.1 (64-bit .NET Core 4.6.28008.02)
[xUnit.net 00:00:06.55]   Discovering: 2CSharp.Tests
[xUnit.net 00:00:06.64]   Discovered:  CSharp.Tests
[xUnit.net 00:00:06.65]   Starting:    CSharp.Tests
[xUnit.net 00:00:07.27]   Finished:    CSharp.Tests


  √ LaTeX2CSharp.Tests.CSharpTests.A100_SimplePower [1ms]
  √ LaTeX2CSharp.Tests.CSharpTests.A050_SimpleRoot [1ms]
  ! LaTeX2CSharp.Tests.CSharpTests.A140_NumberInVarName [1ms]
etc.

I have the exact same problem…

This error case happens whenever we try to run any class library (not just netstandard).

• The host doesn’t find .runtimeconfig.json - so it thinks it should be a self-contained app
• It doesn’t find hostpolicy either - and fails

I don’t think there’s any specific bit of information which the host could use to determine the exact scenario. What we could do is extend the error message with something like:

A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Users\supei\xd\sims\fooo\Main\bin\Debug\netcoreapp2.2\'.
Please make sure that `C:\Users\supei\xd\sims\fooo\Main\bin\Debug\netcoreapp2.2\ClassLib.dll` is an application. It's not possible to directly execute class libraries and other types of dependent projects.
Failed to run as a self-contained app. If this should be a framework-dependent app, add the C:\Users\supei\xd\sims\fooo\Main\bin\Debug\netcoreapp2.2\FooA.runtimeconfig.json file specifying the appropriate framework.

As mentioned in the preceding posts, in most cases the actual source of the issue seems to be that *test.dll is the default when creating a VSTest task. This includes testhost.dll and the test task tries to execute it as a test dll. One way to reduce the frequency in wich this issue occurs is to add the exclusion !*testhost.dll to the default for the VSTest task as it is already done with !*TestAdapter.dll. Concerning a better error message, adding something like "If this error occurs in a test task, excluding testhost.dll via !**testhost.dll may solve the issue" might help users to find a solution pretty fast.

I came to this page because of having the same message in my logs.

TLDR: I was able to solve my problem by removing a project reference from one test-assembly to another.

Long description with a hint about searching for causes of failed builds: Have the same issue with an in azure hosted build agent and with an on-prem build agent when running a VSTest task:

- task: VSTest@2
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: |
        **\YYY.*.Tests.dll
        !**\obj\**
    searchFolder: '$(System.DefaultWorkingDirectory)'
    diagnosticsEnabled: true
    codeCoverageEnabled: true

As you can see in the task definition, it specifies to only get files matching “YYY.*.Tests.dll”, which only includes my test projects.

Unfortunately, when clicking on the link of the commit hash of the “run”, you see the changes of that particular commit - not the changes between ins run and the previous run. Between the last “successful run” and the first “failing run” I did several commits locally that I pushed to Azure DevOps in one single push operation.

So, the changes shown with the “failing run” may not include the cause of the failure - you have to find the changes between the two commits manually.

I had this same problem today and upgrading to Microsoft.NET.Test.SDK version 16.6.1 did not solve it. But some other comments in this thread helped me, so here is my story, hopefully it helps someone 😃

The problem in my case was inheritance.

I had a Shared XUnit test project that:

• Tested some shared functionality that is in a Shared library
• Provided two base test classes to be used by other test projects

Due to the second point, all other test projects were referencing to this Shared test project and therefore the Azure Pipelines test runner was trying to run the Shared test project after each and every other test project. And, for some reason that was failing.

I created a separate project for the two base test classes and removed the references to Shared test project. This solved the problem in my case (I also named the new project so that the filter does not pick it up).

BTW: Everything worked fine when run locally on Visual Studio, but the tests failed when I ran them in the Azure Pipeline.

Add this json to the application.runtimeconfig.json file. { “runtimeOptions”: { “tfm”: “netcoreapp2.2”, “framework”: { “name”: “Microsoft.NETCore.App”, “version”: “2.0.0” } } }

My guess is that:

• The app path is .\srm.dll and because the process starts with current directory in D:\Windows\system32 it gets resolved as D:\Windows\system32\srm.dll.
• D:\Windows\system32\app.dll exists - it’s part of Windows (it’s a native dll). But the host doesn’t look into the file, the fact that it exists is enough to “try to run it”.
• But no other .NET related files are there, so the host is effectively confused and for historical reasons treats the app as self-contained - and fails to find hostpolicy.dll in it. (Note that it thinks the application directory is D:\Windows\system32).

If you rename your app to any name which cannot be found in System32 I would expect the process to fail, unless there’s some other magic which tries it multiple times with different “current directory”.

I think the root issue here is that the hosting should not run with current directory set to System32. There should be a well defined, application dependent directory which is used as the current directory. Or alternatively it should not allow relative paths in the configuration - as those can be easily misinterpreted.

When you encounter this problem with vstest (mstest, xunit or nunit), please update your Microsoft.NET.Test.SDK to 16.6.1 where this problem was solved. https://github.com/microsoft/vstest/commit/3726dae401bd4ca1e8cbe16d869cab5e9d673ed6

Hey all, I came across, and fixed (for me) the same error today when setting up a build in Azure. I was playing around with the command-line test runner, wondering if it was an issue with different assemblies using different .NET versions (I’ve had problems with that before, we have a couple of rather large solutions with multiple projects using different .NET versions), and noticed that one of the assemblies was appearing in the \bin directory for one of the others.

Once this was fixed (i.e. move the ‘shared’ code up into a common assembly), everything started working.

Before:

TestAssembly1 -> reference TestCommon TestAssembly2 -> reference TestCommon & TestAssembly1

After:

TestAssembly1 -> reference TestCommon TestAssembly2 -> reference TestCommon

Hope this helps someone else 😃

The host will always first look for hostfxr next to the executable, then fallback to DOTNET_ROOT, followed by shared global installs.

For the DOTNET_ROOT environment variable, it is expected to point to the root directory with a specific layout - when that variable is set, the host will look for hostfxr under %DOTNET_ROOT%\host\fxr\<version>.

I haven’t been able to think of a way to configure having the testhost.exe be able to handle being given a self-contained config. Running the testhost.dll through dotnet.exe would work though - e.g. dotnet exec --runtimeconfig <pathToRuntimeConfigJson> --depsfile <pathToDepsJson> <nugetCache>\microsoft.testplatform.testhost\16.4.0\build\netcoreapp2.1\x64\testhost.dll

Thanks for the repro @mikail-gultekin. Would you be able to check if you still hit this issue if you don’t make the test project self-contained (should just be removing the <RuntimeIdentifier> property)?

It looks like this is an issue when the test project is set to build self-contained. I was able to repro the same error by grabbing the unit-testing-using-dotnet-test sample and adding <RuntimeIdentifier>win10-x64</RuntimeIdentifier>.

I think this is because, when run through VS, testhost - which appears to be a built apphost - is used to discover tests and given the runtimeconfig and deps files of the test project through the --runtimeconfig and --depsfile command line arguments. The runtimeconfig of the test project indicates that it is self-contained (which dictates where the host looks for hostpolicy), but the testhost app is not, leading to the error. The desired host behaviour around this is not clear to me: #33207.

The .NET Core Test Explorer extension in VSCode runs through dotnet test directly to discover and then run, so it does not hit this.

Hi,

In our team at my company, all the developers have this problem when we try to run tests on Visual Studio Test Explorer. Here is the test compiler output message:

Microsoft.VisualStudio.TestPlatform.ObjectModel.TestPlatformException: Testhost process exited with error: A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Program Files\dotnet'.
. Please check the diagnostic logs for more information.
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyOperationManager.ThrowExceptionOnConnectionFailure(Int32 connTimeout)
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyOperationManager.SetupChannel(IEnumerable`1 sources, String runSettings)
   at Microsoft.VisualStudio.TestPlatform.CrossPlatEngine.Client.ProxyDiscoveryManager.DiscoverTests(DiscoveryCriteria discoveryCriteria, ITestDiscoveryEventsHandler2 eventHandler)

Project settings (from .csproj):

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <StartupObject>TestAutomation.Tests.Program</StartupObject>
    <ApplicationIcon />
    <OutputType>Exe</OutputType>
    <PublishTrimmed>false</PublishTrimmed>
    <PublishReadyToRun>false</PublishReadyToRun>
    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
  </PropertyGroup>

We use x64 based PCs. Processor Architecture for AnyCPU Projects: x64

Any ideas to solve our case?

Thanks.

Would you recommend just invoking Program.Main over testing against a published version of my app?

Depends on what the goal of the test is. I would keep at least some tests which start the process - to have a full E2E validation. But for unit-test-style testing, I would prefer something more direct. Either invoke Main or maybe even true unit testing by invoking internal classes (and use InternalsVisibleToAttribute). But this is just a personal bias, so take it with a grain of salt. The main reasons I prefer more direct testing:

• It’s faster - executing a separate process is a surprisingly expensive operation. It looks fast if you do it once, but if you have 100s of tests it quickly adds up to seconds and more.
• Debugging - it makes debugging tests much more complicated. Different process, have to attach, or recreate start conditions, may need 2 debuggers to debug the product and the tests, …

I’m involved in projects which use both approaches

• the .NET host tests in the runtime repo run external processes - debugging this is tedious and perf is not great (but in lot of cases it has to be done this way).
• the ILLink (trimmer) tool is a command line app, but almost all the tests use something very similar to invoking Main (it goes a bit deeper, but only a little bit). The debugging comfort this offers is invaluable. And the perf is also a lot better.

@asasine This is a known limitation of publish currently. In short all three restore, build and publish need to be done with the same properties, otherwise it’s not guaranteed to work (using --no-restore and --no-build that is).

In this case it’s exaggerated by the unfortunate behavior that specifying just --runtime linux-x64 automatically implies --self-contained true. So in your sample the build is done as self-contained, while the publish is then done as framework-dependent - and things breaks.

I would recommend to not use --no-build (and in some cases also --no-restore) as it tends to break publish in “weird” ways. If you set everything in the project file and only run dotnet build, dotnet publish --no-build - that should work, but adding more to the command line can cause weird behavior.

I have this error when:

TestProjectA -> references TestProjectB

Solution is:

1. Eliminate the reference and place common dependencies in a Shared lib, as it is mentioned by @foggerty

Or

1. Setup ignore filters properly, to exclude project TestProjectB from execution, when referenced by TestProjectA

e.g.

**\bin\**\*.IntegrationTests.dll
!**\obj\**
!**\TestProjectA\bin\**\TestProjectB.dll

Just want to make some things easier to read:

• When there’s no runtimeconfig.json or it doesn’t contain framework/frameworks property then it represents a self-contained app. (This includes the case where there’s includedFrameworks property - that one is only used for self-contained apps and is only used for dynamic loading of dependencies - which is typically not used at all by test projects).
• Self-contained apps are expected to have the hostfxr (and hostpolicy) in the same folder as the app executable.

I think we need to first figure out what is the story around self-contained and tests:

• What are the scenarios where having a self-contained test is useful (I can sort of think about a few, but none feels very compelling to me, so I would like to understand if there are good ones here)
• Do we want to support self-contained tests? We need to be explicit about this - currently we’re not.
  • If the answer is yes than we need to invest into it - given the experience described in this issue there are obviously gaps here. For example I don’t think we treat test projects as “executables” always - I suspect that we treat them as classlibs for a large portion of the SDK. This can obviously create issues.
  • If the answer is no then we should try to actively prevent it - with at least a warning and suggestion what to do.

Similarly I think we need to be explicit about supporting OutputType=exe within test projects. This does weird things:

• It creates a mytest.exe in the output - which does nothing (it runs the auto-generated Main which is a no-op). Basically very confusing - if I get an .exe I should be able to run it. Or at the very least it should tell me “this is not how you run this thing”.

Also worth looking into is interaction between running tests and publish properties like PublishTrimmed and similar.

There are specific issues which makes the experience worse:

• Specifying a RID in the project file makes the result self-contained - this is a bad default. I think @richlander is trying to change this for .NET 5, but if and how is still largely undecided.

Other random observations:

• Using dotnet test -r win-x64 has completely different effect from my expectations - the -r in this case means “result directory”, not RID. Seems very confusing.

Tried this and I am able to trigger this with:

// file UnitTest1.cs
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace UnitTestProject36
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void TestMethod1()
        {
        }
    }
}

<!-- file UnitTestProject36.csproj -->
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>    
    <IsPackable>false</IsPackable>
    
     <!-- need both to see the behavior -->
    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
    <OutputType>Exe</OutputType>
  </PropertyGroup>

  <ItemGroup>
    <!-- does not fail before 16.4.0 -->
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.4.0" />   
    
    <PackageReference Include="MSTest.TestAdapter" Version="2.0.0" />
    <PackageReference Include="MSTest.TestFramework" Version="2.0.0" />
  </ItemGroup>

</Project>

Ultimately it boils down to this. The RED is the one that fails:

The problem can be replicated also by running the test host by itself using the commands we see in logs and reducing the parameters to just depsfile and runtime config (don’t get confused by the access denied error in the second case, that is test host running correctly):

PS> & '~\.nuget\packages\microsoft.testplatform.testhost\16.4.0\build\netcoreapp2.1\x64\testhost.exe' --depsfile .\UnitTestProject36.deps.json --runtimeconfig .\UnitTestProject36.runtimeconfig.json
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Program Files\dotnet'.


PS> & '~\.nuget\packages\microsoft.testplatform.testhost\16.4.0\build\netcoreapp2.1\x64\testhost.exe' --depsfile .\UnitTestProject36.deps.json --runtimeconfig .\good.runtimeconfig.json
Unhandled exception. System.ComponentModel.Win32Exception (5): Access is denied.

@elinor-fung do you see anything that we could do to allow the test host to run?

@joanna1010 As was already mentioned above in this issue, classlib projects are not meant to be executed via dotnet project.dll. Ignoring all other problems, what method should that actually invoke in the managed code? Applications have clearly defined entry point - the Main. But classlibs don’t have anything like that.

I do agree that it would be nice to provide a better error message, and we’ll try to look into that.

Regarding Azure Functions - I don’t know how exactly should Azure Functions be executed, but I would be very surprised if it was dotnet classlib.dll. If you’re having issues running your Azure Function project, please create an issue in the respective area. I don’t know for sure, but https://github.com/Azure/Azure-Functions looks promising.

I don’t think that’s bug or something need change, you can not run dotnet/dotnet exec with a class library, the class library had no entry point for an executable program, maybe more clearly error info