109 votes

La bibliothèque hostpolicy.dll n'a pas été trouvée.

J'ai un projet .NET Core simple (application console) que j'essaie de compiler et d'exécuter. dotnet build réussit, mais j'obtiens l'erreur suivante quand je fais 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].

Mon project.json ressemble à ceci :

{
  "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"
}

Qu'est-ce que hostpolicy.dll et pourquoi est-il absent ?

2 votes

Je suis tombé sur cette erreur en essayant d'exécuter un DotnetCliTool personnalisé avec Visual Studio 2017 RC3 auquel il manquait un runtimeconfig.json. La prochaine version de VS le contiendra par défaut. github.com/dotnet/cli/issues/5593#issuecomment-277638612

0 votes

La même erreur peut s'afficher, si vous exécutez dotnet MyApp.exe, exécutez simplement MyApp.exe "La bibliothèque 'hostpolicy.dll' est requise" si elle est exécutée à partir du dossier deploy, mais emitEntryPoint est vrai.

1 votes

Avec la sortie de asp.net core 2.1, la tâche de publication webjob présente un bogue/une régression qui peut provoquer cette erreur si vous ciblez le framework complet. La solution est d'épingler le SDK à la version 2.1.200 jusqu'à ce que le problème soit résolu. Vous pouvez également supprimer le fichier run.cmd pour remettre rapidement en marche vos travaux de production.

3voto

Je ne sais pas pourquoi, mais j'ai rencontré le problème en exécutant le fichier .exe dans mon ordinateur. \bin alors que le fichier .exe dans mon dossier \obj fonctionne bien.

3voto

s k Points 1016

Je rencontre ce problème dans une application Console Dotnet Core 3.1.

Si vous publiez votre application, veillez à ce que votre exécution de la cible définie pour le runtime spécifique que vous avez installé sur votre machine cible.

Si vous réglez sur portable il choisira le runtime qui lui convient le mieux (ce qui n'est peut-être pas le cas si vous l'avez installé).

2voto

sandesh kota Points 1006

Pour moi, le problème était lié à la non-concordance des versions. J'avais une version différente de ".Net core SDK" installée et une version différente était spécifiée dans le fichier .json.

Une fois que j'ai modifié la version dans mon fichier .json, l'application a commencé à fonctionner correctement.

2voto

Jonathan DeMarks Points 818

Dans mon cas, c'était parce que je publiais une application autonome pour la mauvaise cible. Mon intention était de fonctionner sur alpine linux, mais je construisais pour libc alors que j'aurais dû construire pour musl .

Le paquet défaillant a été construit en utilisant :

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

Changer le RID :

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

a produit un paquet fonctionnel. Remarquez que le RID est passé de linux-x64 a linux-musl-x64 . Si j'avais lu le Page du catalogue RID de .NET Core cela aurait pu être évité.

1voto

iksess Points 66

Peut-être que vous ne vouliez pas faire un projet "Console .Net Core" mais un projet "Console .Net Framework". Cela résout le problème, pour moi...

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X