2017-10-19 21 views
4

J'utilise Visual Studio for Mac, mon application est écrite, elle fait ce que je veux. La plate-forme cible de l'utilisateur est OSX. Elle repose sur 2 paquets NuGet avec leurs propres dépendances, en particulier:Comment distribuer une application console .net core 2.0 sur osx

  • NetMQ
  • Microsoft.Extensions.Configuration.CommandLine

je lance la commande suivante pour build l'application:

dotnet build -c Release -r osx.10.11-x64 

La sortie me dit qu'il a réussi et me montre où il a mis les fichiers.

contenus dans ce dossier sont les fichiers suivants, ce dossier est ce que je suppose que je distribuerai à mon utilisateur, mais cela conduit à des erreurs d'où cette question:

MyApp <---- executable 
MyApp.deps.json 
MyApp.dll 
MyApp.pdb 
MyApp.runtimeconfig.dev.json 
MyApp.runtimeconfig.json 
libhostfxr.dylib 
libhostpolicy.dylib 

donc mon utilisateur reçoit cela et ils ont le dotnet runtime installé. Quand ils vont lancer l'exécutable (ici MyApp aka ./MyApp) ils reçoivent l'erreur suivante:

An assembly specified in the application dependencies manifest (MyApp.deps.json) was not found: 
package: 'AsyncIO', version: '0.1.26' 
path: 'lib/netstandard1.3/AsyncIO.dll' 

Maintenant, AsyncIO est une dépendance de NetMQ si c'est là qui vient. Cependant, je peux ./MyApp de n'importe où sur mon système de fichiers et cela fonctionne. Je pense donc que les paquets Nuget installés sur mon système en tant que système de développement sont toujours accessibles là où ils ne le sont pas sur le système des nouveaux utilisateurs. Je n'ai pas vraiment trouvé de documentation concernant la distribution à partir d'un Mac. La seule chose que je peux penser à faire maintenant est de distribuer les fichiers de projet au lieu et demander à l'utilisateur d'exécuter:

dotnet run -p MyApp.csproj 

qui, si je comprends bien, installera les paquets de NuGet.

Je peux également l'utilisation de l'utilisateur:

dotnet MyApp.dll 

Je l'ai vu cette forme autour de mon googling. Cela les amène à s'interroger sur la raison pour laquelle un exécutable est généré. Les mendiants ne peuvent pas être des sélecteurs, si le moyen de le faire dotnet <dll> Je suis heureux, j'ai juste besoin de le faire fonctionner.

Il doit y avoir quelque chose qui me manque ici ou bien ce détail, la distribution, des applications de netcore2.0 a été juste négligé?

En creusant un peu plus autour de cela semble aussi comme une commande utile:

dotnet publish -c Release --framework netcoreapp2.0 --runtime osx.10.11-x64 

Et qui ajoute toutes sortes de DLL et toutes les DLL de dépendance ainsi. Des mots comme publish me font penser que c'est la façon dont cela doit aller.

Ces 2 liens sont là où je suis surtout reçois mes infos:

https://docs.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli https://docs.microsoft.com/en-us/dotnet/core/tools/project-json-to-csproj

Répondre

3

Vous avez la bonne intuition sur la différence entre build et publish.

dotnet build va construire l'application pour le développement local. Un aspect est que la construction supposera que toutes les dépendances sont disponibles via le cache de nuget local.

dotnet publish va générer l'application pour le déploiement vers d'autres machines. Cela traite explicitement des dépendances.

Il existe deux modes de publication: les déploiements autonomes et les déploiements dépendant de la structure.

Les déploiements dépendant du framework fonctionnent en s'appuyant sur une infrastructure déjà présente sur le système. Si vous publiez votre application dans ce mode, vous inclurez uniquement votre application et ses dépendances.

Pour publier dans un FDD, utilisez:

dotnet publish -c Release --framework netcoreapp2.0 

déploiements auto-containted, en revanche, comprendra l'exécution entière Core .NET et votre application et ses dépendances.

Pour publier un SCD, utilisez:

dotnet publish -c Release --framework netcoreapp2.0 --runtime osx-x64 

(BTW, s'il vous plaît utilisez-le plus général osx-x64 plutôt que le très spécifique osx.10.11-x64)

Voyez-vous la différence entre les deux modes de publication ? C'est juste la présence/absence de l'identifiant d'exécution. Lorsque, dans votre exemple, vous utilisez le flag --runtime, vous demandez à ce que votre application soit publiée en tant que SCD, ce qui inclut également tout le runtime .NET Core. Il suffit de laisser tomber et vous devriez obtenir ce que vous attendez. Lorsque vous publiez votre application en tant que FDD, vous devriez voir un répertoire appelé bin/Release/netcoreapp2.0/publish dans votre code source. Utilisez ce répertoire (et pasbin/Release/netcoreapp2.0/) comme archive de version. Vos utilisateurs devraient simplement exécuter dotnet ./path/to/publish/MyApp.dll. Pour plus d'informations, consultez https://docs.microsoft.com/en-us/dotnet/core/deploying/.