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

[peterhuene]

_From @sillyousu on Tuesday, 30 April 2019 02:19:35_

Steps to reproduce

create a hello world project:

mkdir ClassLib
cd ClassLib
dotnet new classlib
cd ..
mkdir Main 
cd Main
dotnet new console
dotnet  add reference ..\ClassLib\ClassLib.csproj
dotnet build
dotnet .\bin\Debug\netcoreapp2.2\ClassLib.dll

.
├── ClassLib
│   ├── Class1.cs
│   └── ClassLib.csproj
└── Main
    ├── Main.csproj
    └── Program.cs



md5-7b6799f37898cea7c3d2bca8ddfe5ff3



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\'.
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.



md5-366127fc6e73361ed1f3c7ccedad5cb5



PS C:\Users\supei\xd\sims\fooo\Main> dotnet.exe --info
.NET Core SDK（反映任何 global.json）:
 Version:   2.2.100
 Commit:    b9f2fa0ca8

运行时环境:
 OS Name:     Windows
 OS Version:  10.0.17763
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.2.100\

Host (useful for support):
  Version: 2.2.0
  Commit:  1249f08fed

.NET Core SDKs installed:
  1.1.8 [C:\Program Files\dotnet\sdk]
  1.1.9 [C:\Program Files\dotnet\sdk]
  1.1.11 [C:\Program Files\dotnet\sdk]
  2.1.101 [C:\Program Files\dotnet\sdk]
  2.1.103 [C:\Program Files\dotnet\sdk]
  2.1.104 [C:\Program Files\dotnet\sdk]
  2.1.200 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.300 [C:\Program Files\dotnet\sdk]
  2.1.403 [C:\Program Files\dotnet\sdk]
  2.1.500 [C:\Program Files\dotnet\sdk]
  2.1.602 [C:\Program Files\dotnet\sdk]
  2.2.100 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

_Copied from original issue: dotnet/cli#11267_

[peterhuene]

@sillyousu thank you for reporting this issue.

@vitek-karas is there something we could do in the host to have a more helpful error message for users when someone accidentally execs a netstandard assembly?

[vitek-karas]

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.

[borysl]

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

[WeihanLi]

I met the error with dot net framework project

[vitek-karas]

@borysl @WeihanLi - I'm just trying to understand your comments better:

• Is it that you've ran into this by also trying to run a non-app project and are simply reporting the fact that the error message is confusing?
• Is it that you were trying to do something you think should work and it failed?

The scenario described above is supposed to fail, this issues is about the fact that the failure message is rather confusing.

[WeihanLi]

Thanks for your reply @vitek-karas , this is not exactly the same with my scene, I'm running a web project with dotnet framework, so I opened a new issue here https://github.com/dotnet/core-setup/issues/7149

[AbhishekHumagain]

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

[WeihanLi]

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

[joanna1010]

I am having the same issue when deploying my Function app in Azure.

Going into https://my-web-app.scm.azurewebsites.net
and trying to do dotnet myapp.dll
here's the output

By default, Function app boilerplate makes it as class library and you can deploy that dll straight into Azure, means it must be able to be executed properly right?

[vitek-karas]

@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.

[Smurf-IV]

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.

[rob83ert]

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...

[Smurf-IV]

@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.

[Interface007]

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.

[MichaelSchreiber]

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.

[GitSnafu]

I just got hit by this issue after upgrading my app to netcoreapp3.1 from netcoreapp3.0.

In my case the hostpolicy.dll simply doesn't exist in C:Program FilesdotnetsharedMicrosoft.NETCore.App3.1.0. In fact there's only a single file in that folder so it looks like the 3.1 runtime installation is incomplete/corrupted. Note that it still comes up as being installed when running dotnet --list-runtimes.

Microsoft.AspNetCore.All 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] 
Microsoft.AspNetCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 
Microsoft.AspNetCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 
Microsoft.NETCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 
Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 
Microsoft.NETCore.App 3.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 

[vitek-karas]

@GitSnafu Would be interesting to know how you installed it (and if the installation failed). The way dotnet checks for frameworks is simply by looking for a folder with a given name, it doesn't check the contents (it trusts the installer to do its job). So it's not surprising that it reports the framework as available even if there's nothing in it.

What file is in that folder?

You should be able to fix this by reinstalling 3.1 I think.

[GitSnafu]

@vitek-karas Yes, re-installing it most likely will fix the issue, which is why I thought it was worth mentioning it in case anyone else encounters this error for similar reasons.

The only file in that folder was mscordaccore_amd64_amd64_4.700.19.56402.dll.

I believe it was installed using Ansible. All other servers I've checked that would've also had it installed in the same way look good, so it seems like there was just an issue with this particular instance.

[vitek-karas]

So far I was only able to determine that such file is used by dump debugging (!analyze in windbg). Would be interesting to know how exactly it got installed, as such action is effectively breaking for the .NET Core installation on the machine.

[AudricCh]

Hi,

I wanna know where we are about this.

I'm trying to use a dotnet command to generate a swagger file using SwashBuckle

dotnet swagger tofile --output ./ ./MyApi/bin/Debug/net47/MyApi.dll swagger.json

And I've got the following message

A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'D:MyApibinDebugnet47'.
Failed to run as a self-contained app. If this should be a framework-dependent app, specify the appropriate framework in D:MyAppbinDebugnet47MyApi.runtimeconfig.json.

And the MyApi.runtimeconfig.json file looks great :
{ "runtimeOptions": { "tfm": "net47", "configProperties": { "System.GC.Server": true } } }

Is it just about the NetCore / NetStandard compatibility ?
Thanks

[vitek-karas]

@AudricCh You're trying to run .NET Framework application on .NET Core - that is not going to work. The net47 TFM is .NET Framework 4.7.

The interesting question in this case would be how did you build the app such that it produced .runtimeconfig.json even for net47 TFM. That should not happen.

Can you please file a new issue for that in https://github.com/dotnet/sdk repo? Thanks a lot!

[mikail-gultekin]

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.

[vitek-karas]

@mikail-gultekin just to make sure - please check that you have VS setup to run tests with x64 (I think it's a separate setting from how to run AnyCPU - it's under the Test menu)

[vitek-karas]

@elinor-fung Another good candidate for improving error messages in the hosting space. In this case I would say there are in fact two scenarios we should try to differentiate:

• Missing hostpolicy - and we're looking for it in the app's folder (probably missing .runtimeconfig.json or broken self-contained app)
• Missing hostpolicy - and we're looking for it in the global location "ProgramFiles/dotnet". This needs investigation as to when exactly it happens and then come up with a reasonable error message for that case.

[mikail-gultekin]

@mikail-gultekin just to make sure - please check that you have VS setup to run tests with x64 (I think it's a separate setting from how to run AnyCPU - it's under the Test menu)

you mean Processor Architecture for AnyCPU Projects setting?If it is, I have already set it to x64 and still no luck. Thanks for quick reply btw.

[mikail-gultekin]

If anyone interested; I could not wait until this problem to be solved so I tried VSCode. I run & debug all my test cases without any problem.

[elinor-fung]

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.

[nohwnd]

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()
        {
        }
    }
}

```csproj

netcoreapp3.1
false

 <!-- need both to see the behavior -->
<RuntimeIdentifier>win10-x64</RuntimeIdentifier>
<OutputType>Exe</OutputType>

<PackageReference Include="MSTest.TestAdapter" Version="2.0.0" />
<PackageReference Include="MSTest.TestFramework" Version="2.0.0" />

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

![image](https://user-images.githubusercontent.com/5735905/76096132-d7af3000-5fc5-11ea-9bc4-b1563677178c.png)

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):

```powershell
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?

[nohwnd]

Here is how the test host searches for the hostpolicy.
First line is where the failing test host searches for the hostpolicy, the rest of the lines is the working test host :

The testhost will fail to run with any of the runtimeconfigs when dotnet root is set to a path that does not have any dotnets:

PS> & '~\.nuget\packages\microsoft.testplatform.testhost\16.4.0\build\netcoreapp2.1\x64\testhost.exe' --depsfile .\UnitTestProject36.deps.json --runtimeconfig .\good.runtimeconfig.json
A fatal error occurred, the required library hostfxr.dll could not be found.
If this is a self-contained application, that library should exist in [C:\Users\jajares\.nuget\packages\microsoft.testplIf this is a framework-dependent application, install the runtime in the default location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location.

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 occurred, the required library hostfxr.dll could not be found.
atform.testhost\16.4.0\build\netcoreapp2.1\x64\].
If this is a framework-dependent application, install the runtime in the default location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location.

Running the .\UnitTestProject36.exe produces no error, but I can confirm that it executed, and I see it pick up the hostpolicy from the current folder.

Copying the testhost.exe into the output folder will also allow it to run correctly.

I was not able to find any combination of parameters and env variables that would allow me to run the testhost.exe from the nuget cache with the configs from the project without requiring the runtime to be available in a shared folder.

---

These are my logs:

C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64> $env:COREHOST_TRACE=1; $env:COREHOST_TRACE_VERBOSITY=3;        

C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64> .\testhost.exe
Tracing enabled
--- Invoked apphost [version: 2.1.0, commit hash: caa7b7e2bad98e56a687fb5cbaf60825500800f7] main = {
C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\testhost.exe
}
The managed DLL bound to this executable is: 'testhost.dll'
Resolved fxr [C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\hostfxr.dll]...
Loaded library from C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\hostfxr.dll
Invoking fx resolver [C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\hostfxr.dll] v2
Host path: [C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\testhost.exe]
Dotnet path: [C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\]
App path: [C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\testhost.dll]
Tracing enabled @ Fri Mar  6 16:20:27 2020 GMT
--- Invoked hostfxr_main_startupinfo [commit hash: 916b5cba268e1e1e803243004f4276cf40b2dda8]
Detecting mode... CoreCLR present in dotnet root [C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\] and checking if [testhost.deps.json] file present=[0]
Using dotnet root path [C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\]
Loaded library from C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\hostpolicy.dll
Tracing enabled @ Fri Mar  6 16:20:27 2020 GMT
--- Invoked hostpolicy [commit hash: 916b5cba268e1e1e803243004f4276cf40b2dda8] [runtime.win-x64.Microsoft.NETCore.DotNetHostPolicy,3.1.2,runtimes/win-x64/native][x64] corehost_main = {
C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\testhost.exe
}
Deps file:
Loaded library from C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\coreclr.dll
Launch host: C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\testhost.exe, app: C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\testhost.dll, argc: 0, args:
Unhandled exception. System.ComponentModel.Win32Exception (5): Access is denied.
  ^^^^ access denied means success 


C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64> & "C:\Users\jajares\.nuget\packages\microsoft.testplatform.testhost\16.4.0\build\netcoreapp2.1\x64\testhost.exe" --runtimeconfig "C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\UnitTestProject36.runtimeconfig.json" --depsfile "C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\UnitTestProject36.deps.json"
Tracing enabled
--- Invoked apphost [version: 2.1.0, commit hash: caa7b7e2bad98e56a687fb5cbaf60825500800f7] main = {
C:\Users\jajares\.nuget\packages\microsoft.testplatform.testhost\16.4.0\build\netcoreapp2.1\x64\testhost.exe
--runtimeconfig
C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\UnitTestProject36.runtimeconfig.json
--depsfile
C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\UnitTestProject36.deps.json
}
The managed DLL bound to this executable is: 'testhost.dll'
Using default installation location [C:\Program Files\dotnet] as runtime location.
A fatal error occurred, the required library hostfxr.dll could not be found.
If this is a self-contained application, that library should exist in [C:\Users\jajares\.nuget\packages\microsoft.testplatform.testhost\16.4.0\build\netcoreapp2.1\x64\].  If this is a framework-dependent application, install the runtime in the default location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location.



-------  I set the DOTNET_ROOT but still no dice ----- 

C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64> $env:DOTNET_ROOT="C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\"
C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64> & "C:\Users\jajares\.nuget\packages\microsoft.testplatform.testhost\16.4.0\build\netcoreapp2.1\x64\testhost.exe" --runtimeconfig "C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\UnitTestProject36.runtimeconfig.json" --depsfile "C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\UnitTestProject36.deps.json"
Tracing enabled
--- Invoked apphost [version: 2.1.0, commit hash: caa7b7e2bad98e56a687fb5cbaf60825500800f7] main = {
C:\Users\jajares\.nuget\packages\microsoft.testplatform.testhost\16.4.0\build\netcoreapp2.1\x64\testhost.exe
--runtimeconfig
C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\UnitTestProject36.runtimeconfig.json
--depsfile
C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\UnitTestProject36.deps.json
}
The managed DLL bound to this executable is: 'testhost.dll'
Using environment variable DOTNET_ROOT=[C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\] as runtime location.
A fatal error occurred, the required library hostfxr.dll could not be found.
If this is a self-contained application, that library should exist in [C:\Users\jajares\.nuget\packages\microsoft.testplatform.testhost\16.4.0\build\netcoreapp2.1\x64\].  If this is a framework-dependent application, install the runtime in the default location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location.
C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64> gi C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64\hostfxr.dll


    Directory: C:\Projects\temp\UnitTestProject36\UnitTestProject36\bin\Debug\netcoreapp3.1\win10-x64

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        17/01/2020    21:24         599424 hostfxr.dll

@elinor-fung I am out of options here, it seems that what ever I try the host will look for hostfxr next to the executable, ignoring the DOTNET_ROOT. Is there a variable / param I am missing?

[elinor-fung]

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

[nohwnd]

@elinor-fung one possible way to do this is to set the DOTNET_ROOT to the self-contained folder, and create a symlink to hostfxr from the self-contained folder that is in the correct relative path (host/fxr/version). This will allow testhost.exe run even if it not next to the hostfxr. But that is definitely not a production-ready solution.

I am patching the testhost targets to copy the .exe into the output folder, which allows the .exe to be picked up from the folder, before falling back to the .nuget location.

[vitek-karas]

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.

[nohwnd]

Specifying a RID in the project file makes the result self-contained

I will fix the copying of testhost.exe into the output. The targets file specifies to do this on Publish, and because the build now behaves like publish I think it is okay to do this.

Do we want to support self-contained tests? We need to be explicit about this - currently we're not.

I agree that this needs more discussion, and will discuss these points with our team. Thanks for the summary!

[foggerty]

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 :-)

[vitalybibikov]

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

[NaomiN]

So, what is the solution? I created a very simple console app, built it. I am able to run this exe from the objReleasenetcoreapp3.1 folder on my local, but when I copy content of that folder to another computer, I'm getting that error. I used all the defaults when creating my exe (used VS 2019)

[vitek-karas]

@NaomiN You should not use the files in obj those are intermediate build assets, they might or might not work even locally. The working output should be in bin\Release\netcoreapp3.1 folder. It should also work if you copy that folder to a different machine - given two assumptions:

• You build on the same OS as you're going to run on (so for example x64 Windows -> x64 Windows)
• The target machine has .NET Core runtime installed on it (ideally the same version)

[NaomiN]

My local is Windows 10 x64, I am using Visual Studio 2019 and I've been trying to copy to Windows Server 2012 (I think). I am not sure about everything installed on the server, I know it has 2017 installed, but I was unable to open that project in VS 2017 as it and I don't have admin rights on that server to install anything.

[vitek-karas]

@NaomiN if the target machine doesn't have the necessary .NET Core runtime installed (and you can't install it yourself) you can use self-contained deployment. Once the app is ready publish it with

dotnet publish -r win-x64 -c Release

This will create a folder like bin\Release\netcoreapp3.1\win-x64\publish which should contain everything the app will need to run (including the .NET Core runtime). You will notice that the folder is quite large (should be more than 100 files and at least 50MB in size, probably more).

If you copy that folder to the target machine it should just work. Make sure that the runtime identifier you pass in to the -r win-x64 matches the target machine. (So if the server is x86 it should be win-x86 for example, but it can be linux/mac anything supported).

Please make sure that the target system is supported as well: https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1-supported-os.md

[nohwnd]

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

[canpolat]

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.

[omghb]

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?