2016-06-28 5 views
15

Ho un semplice progetto .NET Core (app per console) che sto cercando di compilare ed eseguire. dotnet build riesce, ma ottengo il seguente errore quando faccio dotnet run:La libreria hostpolicy.dll non è stata trovata

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

mio project.json si presenta così:

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

Qual è hostpolicy.dll, e perché è scomparsa?

+2

Mi sono imbattuto in questo errore durante il tentativo di eseguire un DotnetCliTool personalizzato con Visual Studio 2017 RC3 che mancava a runtimeconfig.json. La prossima versione VS lo impacchetterà per impostazione predefinita. https://github.com/dotnet/cli/issues/5593#issuecomment-277638612 –

+0

Lo stesso errore può essere mostrato, se si esegue dotnet MyApp.exe, basta eseguire MyApp.exe ["La libreria 'hostpolicy.dll' richiesta "se eseguito dalla cartella di distribuzione, ma emitEntryPoint è true] (// stackoverflow.com/a/38333053) –

risposta

10

Questo messaggio di errore non è utile. Il attuale problema è un emitEntryPoint proprietà mancante:

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

Una volta che questo si aggiunge, il compilatore ti consente di sapere su eventuali altri problemi (come un metodo di static void Main() mancante). La compilazione riuscita del progetto comporterà un output che è possibile eseguire dotnet run.

+3

L'ho archiviato qualche tempo fa: https://github.com/dotnet/cli/issues/2859 – Pawel

+0

Poiché questo è potrebbe accadere ancora in rtm potrebbe essere la pena notare nel repository github per ogni evenienza. –

+2

@NickAcosta - Credo che questo tipo di problemi siano il motivo per cui gli strumenti sono preview2 e non rtm (la pietra miliare per il bug è 1.0.0-rtm). Solo runtime è rtm. – Pawel

6

Aggiornamento per dotnet nucleo 2.0: il file appname.runtimeconfig.json (sia per il debug e rilasciare configurazione) è necessaria nel stesso percorso appname.dll.

Contiene:

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

poi dotnet.exe exec "path/to/appname.dll" [appargs] opere.

+0

Questa risposta era parzialmente pertinente per me poiché utilizzo anche dotnet core 2.0. Non sono sicuro se ho fatto qualcosa di strano nel mio spazio di lavoro, ma ho anche scoperto che avevo .dll nelle directory 'obj' e 'bin'. Ero in 'obj' e ho capito che quello in' bin' aveva già questo file '.runtimeconfig.json'. Correre quello ha funzionato senza modifiche. – voltrevo

1

Per me con ASP.NET Core 2.0 su Azure, era l'appname.deps.json a fare il trucco.

Problemi correlati