2017-03-03 10 views
0

Ich bin eine .NET Core-Konsole App als Standalone-Build auf mehrere Plattformen bereitstellen. Ich habe Probleme, die MacOS-Version zum Laufen zu bringen. Wenn ich die ausführbare Datei ausführe, erhalte ich die folgende Fehlermeldung:.NET Core Standalone-Build wird nicht auf MacOS laufen 10.12

"Fehler: Assembly, die im Manifest der Abhängigkeiten angegeben wurde, wurde nicht gefunden - Paket: 'runtime.osx.10.10-x64.runtime.native.System', Version: '4.3.0', Pfad: 'Laufzeiten/osx.10.10-x64/native/System.Native.a' "

Ich habe die App zu win7-x86, win7-x64, win10-x86 gebaut und bereitgestellt, win10-x64, Centos.7-x64, alles ohne Probleme.

Ich versuche, den Mac auf einem Mac mini laufen Mac OS 10.12 (Sierra) laufen zu lassen. Ich habe versucht, osx.10.10-x64 und osx.10.12-x64 zu targeting und bekomme den gleichen Fehler. Ich habe auch versucht, unter .NET Core 1.0.1 und 1.1.0 wieder mit demselben Fehler zu erstellen und zu veröffentlichen.

Ich baue auf einem Windows 10 System auf und erstelle in jedem Fall eigenständige Builds. Ich habe meine App ordnungsgemäß laufen lassen, als ich das .NET Core-Framework auf dem Mac installiert habe (und die App als Framework-Build erstellt habe), aber ich muss eigenständige Builds ausführen.

Ich habe OpenSSL auf dem Mac über Homebrew installiert, das ist die einzige externe Abhängigkeit, die mir bekannt ist. Meine Projekt.json Datei ist unten.

Jede Hilfe wäre willkommen!

{ 
    "version": "1.1.0-*", 
    "buildOptions": { 
    "emitEntryPoint": true 
    }, 

    "dependencies": { 
    "Microsoft.NETCore.App": "1.1.0", 
    "Newtonsoft.Json": "9.0.1", 
    "System.Xml.XmlSerializer": "4.3.0" 
    }, 

    "frameworks": { 
    "netcoreapp1.1": { 
     "imports": "dnxcore50" 
    } 
    }, 

    "runtimes": { 
    "centos.7-x64": {}, 
    "win10-x64": {}, 
    "win10-x86": {}, 
    "win7-x64": {}, 
    "win7-x86": {}, 
    "osx.10.10-x64": {}, 
    "osx.10.12-x64": {} 
    }, 

    "description": "XXX gameplay instance server.", 
    "title": "XXX" 
} 

Antwort

0

Es scheint ein Umweltproblem zu sein, ein neues Projekt zu erstellen, mit dem Docker und Kopieren Ihre project.json Arbeit als gut.

docker run -v <your app folder>:/app -it --rm microsoft/dotnet:1.1.0-sdk-projectjson 

Im Inneren des Behälters

cd /app 
dotnet restore 
dotnet publish -c Release -r osx.10.12-x64 
exit 

Außerhalb des Behälters

chmod +x bin/Release/netcoreapp1.1/osx.10.12-x64/publish/app 
./bin/Release/netcoreapp1.1/osx.10.12-x64/publish/app 

Verbindung des Testprojekts: https://drive.google.com/open?id=0B9E5H1HYtm8DSFJMSG1CZDNyTGc

+0

Ist es notwendig, Docker in diesem Fall zu benutzen? Ist der Zweck eines eigenständigen Builds nicht vergleichbar mit dem, was Docker bereitstellt, dh eine eigenständige portable Umgebung, die auf dem Zielcomputer ausgeführt werden kann? Ich stimme zu, dass es scheint, ein Umweltproblem zu sein, es scheint, als würde der Veröffentlichungsprozess die richtigen Bibliotheken nicht enthalten. Ich würde es vorziehen, das Kernproblem im Dotnet-Build-Prozess zu beheben, wenn möglich. Aber wenn das nicht funktioniert, ist es eine gute Idee, docker zu probieren. Danke für die Hilfe! –

+0

Nur um klar zu sein, das Andockfenster wird nur verwendet, um die Stand-Alone-App zu veröffentlichen, danach ist das Andockfenster nicht erforderlich. Sie können die App auf einem neuen Host ohne .NET oder Andockfenster kopieren und ausführen. Ich habe ähnliche Probleme mit Standalone-Apps gesehen, und Docker ist der beste Weg, um Umgebungsprobleme zu isolieren. http://stackoverflow.com/questions/42194718/problems-with-net-core-self-contained-publish –

+0

Danke Ricardo, ich werde es versuchen! –

Verwandte Themen