The library hostpolicy.dll was not found

I have a simple .NET Core project (console app) that I'm trying to compile and run. dotnet build succeeds, but I get the following error when I do dotnet run:

dotnet run
Project RazorPrecompiler (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in [path].

My project.json looks like this:

{
  "buildOptions": {
    "warningsAsErrors": true
  },
  "dependencies": {
    "Microsoft.AspNetCore.Razor": "1.0.0",
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0"
    }
  },
  "description": "Precompiles Razor views.",
  "frameworks": {
    "netcoreapp1.0": {
      "imports": [ ]
    }
  },
  "version": "1.2.0"
}

What is hostpolicy.dll, and why is it missing?

Update for dotnet core 2.0 and beyond: the file appname.runtimeconfig.json (for both debug and release configuration) is needed in the same path as appname.dll.

It contains:

{
  "runtimeOptions": {
    "tfm": "netcoreapp2.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "2.0.0"
    }
  }
}

then dotnet.exe exec "path/to/appname.dll" [appargs] works.

This error message is unhelpful. The actual problem is a missing emitEntryPoint property:

  "buildOptions": {
    ...
    "emitEntryPoint": true
  },

Once this is added, the compiler will let you know about any other problems (like a missing static void Main() method). Successfully compiling the project will result in an output that dotnet run can execute.

If I'm not mistaken, one scenario when you can hit the issue is this: You have an integration project that references another application project (not library). In this case, dependentProject.runtimeconfig.json won't be copied to your integration project's output folder and you won't be able to run dependentProject.exe binary because it will throw The library hostpolicy.dll was not found..

There is a Github issue for this and a workaround.

Edit: Should be fixed in .NET SDK 5.0.200.

This occurred when a Visual Studio 2019 preview upgrade .Net Core to the latest preview (specifically .Net Core 3.1.100-preview2-014569).

Reinstalling/repairing .Net Core 3.0.100 solved the problem for me.

I'm not sure why but I ran in to the problem when executing the .exe file in my \bin folder while the .exe in my \obj folder works fine.

I am having this problem in Dotnet Core 3.1 Console application.

If you are publishing your application, make sure that your target runtime set to the specific runtime that you had installed in your target machine.

If you set to portable it will pick whatever runtime that it feels comfortable (which you might not have it installed)

For me the issue was with the version mismatch. I had a different ".Net core SDK" version installed and a different version was specified in .json file.

Once I modified the version in my .json file the application started working fine.

In my case it was because I was publishing a self-contained application for the wrong target. My intent was to run on alpine linux, but I was building for libc when I should have been building for musl.

The failing package was built using:

dotnet publish --self-contained true --runtime linux-x64 --framework netcoreapp2.1 --output /app

Changing the RID:

dotnet publish --self-contained true --runtime linux-musl-x64 --framework netcoreapp2.1 --output /app

produced a functional package. Notice the RID changed from linux-x64 to linux-musl-x64. If I had read the .NET Core RID Catalog page this could have been avoided. 

Maybe you didn't want to do a "Console .Net Core" project but a "Console .Net Framework" project. It solves the problem, for me...

My problem was that I have 2 .NET Core App projects and one is dependent on the other. (so I can then execute that application from that other application) But .NET Core applications (with default config) need <assembly name>.runtimeconfig.json file (to get some launch config) which isn't copied by default.

---

The only solution that worked for me was adding to Project Properties > Build Events (of the dependent project) this command:

COPY "$(SolutionDir)<dependency name>\$(OutDir)<dependency assymbly name>.runtimeconfig.json" "$(SolutionDir)$(ProjectName)\$(OutDir)" /Y

But you can also copy the <dependency assembly name>.runtimeconfig.json file by hand to the dependent project.

---

Note that there should be a better more generic way to do this for every .NET Core App Project automatically.

This error is quite generic. So the real problem can be anything.

In my case (if helps anyone with same issue), I created a Class Library project instead of a Console Application project.

A Class Library DLL can't be runned with MSBuild, even if it has a Main method. Only Console Application DDL can be runned as dotnet <appname>.dll

I had similar problem running tests in VS19.

> ========== Starting test run ========== > > 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'. Failed to run as a self-contained > app.

After digging into it I found the source of the problem:

The full path the the .runtimeconfig.json in the test binary folder was above 255 characters. Renaming the module, so the file path becomes shorter, resolved the problem.

For me with ASP.NET Core 2.0 on Azure, it was the appname.deps.json that did the trick. You need to copy it from your build directory to Azure.

I had this same problem with a .NET Core 3.0 WPF app, but I found that my app wouldn't run in Visual Studio 2019 either.

I discovered on the project properties page (right-click on project > Properties) that the Target framework was set to .NET Core 3.0.

I'd recently updated VS 2019 which had also installed .NET Core 3.1, so I switched to that in the dropdown, and it worked again.

(I also had to update my shortcut to point to the netcoreapp3.1 folder instead of the previous netcoreapp3.0 folder.)

Promoting voltrevo's comment as an answer as I believe this should be the most common case of the problem. When you build your solution, sometimes you might get 2 directories with outputs bin and obj. 'Bin' directory has everything that is needed to run dotnet.exe command. Just run from the bin directory and things should be good. :)

I was getting similar error while running Unit tests using VSTest@2 task in Azure Devops. In my case, the problem was with my testAssemblyVer2 value. I was giving wrong pattern for test dlls.

Below one worked for me.(if you are getting this error with VSTest)

- task: VSTest@2
  displayName: 'Running UnitTests'
  inputs:
    testSelector: 'testAssemblies'
    testAssemblyVer2: |
      $(System.DefaultWorkingDirectory)\SrcFolder\BBBB.UnitTests\**\bin\**\*.BBBB.UnitTests.dll
      $(System.DefaultWorkingDirectory)\SrcFolder\AAAAa.UnitTests\**\bin\**\*.AAAA.UnitTests.dll
      !**\*TestAdapter.dll
      !**\obj\**
    platform: x64
    configuration: Debug
    codeCoverageEnabled: true

So try to give correct pattern value for testAssemblyVer2 input. Make sure its filtering only the required dlls.