A fatal error was encountered. The library 'libhostpolicy.so' required

For me it was the following line that I had to add to the project file's PropertyGroup section that did the trick:

<GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>

After some googleing I found this:
https://github.com/aspnet/aspnet-docker/issues/301

I'm not certain what caused it but it seems to have gone away. It's probably because I had a case mismatch of appSettings.json instead of appsettings.json which meant that the file was not being loaded. Terrible error though.

In my case it was that I had forgot to put appsettings.json to copy on builds.

Hope this helps someone else and get's higher on google searches.

After even more googling, we found this link:

http://szahariev.blogspot.co.nz/2016/10/libhostpolicyso-was-not-found-error.html

which lead us to discover that we'd somehow managed to manually remove the (in our case) <OutputType>Exe</OutputType> line from our .csproj file. So no runtimeconfig.json was created at all.

In my case the problem was specified .dll to run was incorrect (library instead of web application).

First I acvieve successfull service start with

dotnet publish "MyProject.csproj" -c Release -o D:\publish --self-contained --runtime linux-x64

and saw in logs a message about invalid .dll.

Then I correct the .dll and tried to publish self-contained and framework-dependent — both started successfully.

So reason may be tricky.

In my case, I was getting this error on Linux machine for WorkerService. Fixed by installing .Net Core and its SDKs properly.

On top of GenerateRuntimeConfigurationFiles, I also had to replace <TargetFramework>netstandard2.1</TargetFramework> with <TargetFramework>netcoreapp3.1</TargetFramework>.

So it's probably .NET SDK version installation related.

None of the above helped for me, but there is a difference in my case: my project is an aspnet core 3.1 webapi. I followed the instructions of a tutorial and landed at this error message. After a while I came to idea to change the base image in my dockerfile from microsoft/aspnetcore:2.0 to mcr.microsoft.com/dotnet/core/aspnet:3.1 AS runtime similar to the hint on the MS Page about docker images for ASP.NET Core and the error disappeared. So I would say the root cause of this error can be an incompatible base image.

So none of the above answers worked for me, but I finally found the problem, it was something in the .csproj file of the API, and it was causing the docker container hosting the API not to start with the message in the thread title.

This was the line that had been added in PropertyGroup node, presumably when someone had published the file for windows, and then checked in the updated .csproj

<RuntimeIdentifier>win-x64</RuntimeIdentifier>

As it turns out this is a publish option. Removing this sets the project to a default value of portable (in the UI) which is "any" in the file if it were explicitly specified. Removing the line above fixed the problem for me.

Edit

As a side note, I was able to leave the RuntimeIdentifier in the API .csproj file alone (kept win-x64 value) by changing my Dockerfile dotnet publish args to:

RUN dotnet publish ./src/API.csproj --self-contained --runtime linux-musl-x64 --configuration Release --output /app/publish

The important parts being the addition of --self-contained and --runtime linux-musl-x64 for alpine-linux ... this image: mcr.microsoft.com/dotnet/aspnet:3.1-alpine

The build image for this is mcr.microsoft.com/dotnet/sdk:3.1

Not related to Docker but I got the error when trying to debug a Azure Core Function that I created via the command line (Azure Func Core tools). The launch.json in VS Code did not auto-generate properly when I tried to create a new debugger configuration. I then used the Azure Function extension to recreate a new Function App project and copied the launch.json that was generated. This file worked for me.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach to .NET Functions",
      "type": "coreclr",
      "request": "attach",
      "processId": "${command:azureFunctions.pickProcess}"
    }
  ]
}