Introduction

The message that hostpolicy.dll was not found usually means the .NET host cannot launch the application in the way it was built or deployed. This is rarely about one random missing file in isolation. It is usually a mismatch between deployment mode, published output, runtime availability, and the command you used to start the app.

Understand the Two .NET Deployment Models

Modern .NET applications are normally published in one of two modes:

• framework-dependent: the target machine must already have the required .NET runtime installed
• self-contained: the application ships with its own runtime files

hostpolicy.dll problems often happen when the deployment style and the launch environment do not agree. For example, a framework-dependent app may be copied to a machine that lacks the right runtime, or a self-contained publish may be copied incompletely.

Publish First, Then Run the Published Output

A common mistake is running directly from a build output folder or copying only a DLL instead of the full published app. Use dotnet publish and run the result from the publish directory.

dotnet publish -c Release -o out

Then launch from that output:

dotnet out/MyApp.dll

If you copy only the main DLL without the rest of the published files, the host may fail before the application code ever starts.

Check Whether the App Is Framework-Dependent

For a framework-dependent app, the target machine must have the matching runtime installed. Verify what runtimes are present:

dotnet --list-runtimes

Also inspect the app's .runtimeconfig.json file in the output folder. That file shows which framework and version the host is trying to resolve. If the required runtime is missing, install it or republish the app for a target framework that actually exists on the machine.

Publish Self-Contained If You Control the Deployment

If you want the app to run without requiring a preinstalled runtime, publish it as self-contained for the correct runtime identifier.

dotnet publish -c Release -r win-x64 --self-contained true -o out

That output is larger because it includes runtime components, but it reduces dependency on the machine's shared .NET installation.

The key is consistency: publish for the runtime you actually plan to run on, such as win-x64, linux-x64, or osx-arm64.

The Launch Command Must Match the Output Type

Another frequent mismatch is using the wrong launch method. Some outputs are meant to be launched with dotnet MyApp.dll. Others, especially self-contained native executables, are meant to be launched directly.

If the project settings, published files, and startup command do not match each other, the host can fail with missing runtime-library errors even though the project built successfully.

Inspect the Real Deployment Artifact

When this error happens on a server or another workstation, inspect the actual deployed directory rather than only the project file in source control. Check whether the target machine received:

• the application DLL or executable
• the .runtimeconfig.json file
• the .deps.json file
• the rest of the published dependencies

Many hostpolicy.dll incidents are simply incomplete file copies.

Do Not Treat This as a “Download the DLL” Problem

A bad reaction is to search the web for hostpolicy.dll, download it from a random site, and place it into the application folder. That is not a real fix. hostpolicy.dll belongs to a specific .NET host/runtime setup. If the host is misconfigured, a random copied DLL will not produce a reliable deployment.

The fix is to correct the publish mode, runtime installation, or copied output, not to patch the directory with arbitrary binaries.

Common Pitfalls

The most common mistake is running from a partial build directory instead of from the published output.

Another mistake is copying only the main DLL and forgetting the .runtimeconfig.json, .deps.json, and other published files.

Developers also publish framework-dependent output and then deploy it to a machine that does not have the required runtime installed.

Summary

• 'hostpolicy.dll errors usually indicate a mismatched or incomplete .NET deployment, not just one missing file.'
• Decide whether the app should be framework-dependent or self-contained.
• Publish the app and run it from the publish directory, not from a partial copy.
• Check installed runtimes and the app's .runtimeconfig.json for framework-dependent deployments.
• Do not try to fix the issue by downloading a random hostpolicy.dll file.