Mon objectif final est de créer une application console multiplateforme (non Web), donc j'explore .NET Core en ce moment.
Dans mes projets .NET précédents, j'ai fait tout le développement dans Visual Studio, mais j'ai également créé un fichier batch/MSBuild pour que je puisse construire l'ensemble du projet (y compris les configurations, les packages NuGet, les fichiers Zip avec des binaires, etc.) en un seul clic. Voici un exemple d'un projet précédent .
En fin de compte, je veux faire quelque chose de similaire avec mon projet de test .NET Core.
Mais en ce moment, j'échoue à la première étape: je ne peux pas le créer en dehors de Visual Studio, de sorte que le résultat fonctionne sur une autre machine Windows sans .NET Core installé.
(dans la première étape, j'ignore la partie multiplateforme - je serai heureux de la faire fonctionner sur Windows)
J'ai réussi à le faire fonctionner dans Visual Studio 2015 Community Edition comme suit:
créer un nouveau projet dans Visual Studio: "" Nouveau projet "⇒" Web "⇒" Application console (package) "
créer un nouveau profil de publication dans Visual Studio ("Build" ⇒ "Publish" dans le menu).
Cela créera n script PowerShell (et n fichier XML avec des paramètres )
Voici mon projet de test sur GitHub .
Lorsque je fais à nouveau "Build" ⇒ "Publish" dans le menu, Visual Studio exécute apparemment à nouveau le script PowerShell précédemment créé.
Le résultat est légèrement supérieur à 90 Mo, se compose de 825 fichiers dans 598 dossiers et ressemble à ceci:
Lorsque je le copie sur une autre machine (Win 7/.NET 4 installé/.NET Core non installé), cela fonctionne.
Cette réponse et cette réponse sonnent comme je peux utiliser dnu publish
pour obtenir le même résultat via la ligne de commande.
Je comprends que certaines parties de .NET Core déplacent encore des cibles en ce moment, donc apparemment dnu
est maintenant dotnet
à la place .
J'ai donc essayé d'exécuter dotnet publish
(et créé n fichier batch ) pour cela:
dotnet publish "%~dp0\src\CoreTestVisualStudio" -c Release -r win7-x64 -o "%~dp0\release\cli"
Le résultat se compose d'un .exe
fichier et un tas de DLL, seulement 25 fichiers et 1,5 Mo, le tout dans un seul dossier:
De toute évidence, le runtime .NET Core est manquant ici, et comme prévu, cette application se bloque lorsque j'essaie de l'exécuter sur une machine sans .NET Core installé (le même que celui mentionné ci-dessus).
J'ai essayé d'exécuter le script PowerShell (qui a été créé lorsque j'ai créé le profil de publication) en dehors de Visual Studio , mais il a échoué car le script attend certains paramètres et je ne le fais pas savoir quoi passer:
param($publishProperties, $packOutput, $nugetUrl)
Il y a aussi cette ligne dans le script:
# to learn more about this file visit http://go.Microsoft.com/fwlink/?LinkId=524327
... mais le lien pointe simplement vers la page de destination du blog de développement et d'outils Web .NET .
Qu'est-ce que je fais mal?
Je sais que la première version de .NET Core se concentre principalement sur ASP.NET, mais si je comprends bien, les applications ASP.NET Core ne sont que des applications console, donc j'ai pensé qu'une application console de base fonctionnerait maintenant.
D'un autre côté, la plupart des documents de démarrage de l'application console sont toujours manquants, alors c'est peut-être trop tôt et dotnet publish
pour les applications console n'est pas encore terminé?
Modifier après quelques jours: je soupçonne que je ne fais rien de mal et que c'est un problème dans les outils de ligne de commande .NET Core, donc je l'a publié sur le problème des outils de ligne de commande tracker .
Problème résolu!
Je l'ai posté sur le problème de suivi des outils de ligne de commande .NET Core , et il s'est avéré qu'il s'agissait d'un bogue dans dotnet publish
- il n'a pas intégré le runtime C++, qui est nécessaire pour exécuter l'application compilée sur une machine sans .NET Core installé.
La solution temporaire était d'installer le runtime C++.
La "vraie" solution a été faite dans une demande de tirage il y a trois jours, qui est incluse dans le dernier installateur maintenant.
Avec cette version, dotnet publish
regroupe le runtime C++, donc le résultat fonctionnera sur une machine sans .NET Core.
Pour dnu
:
Il y a une option pour dnu publish
appelé --runtime
qui spécifie le runtime à inclure lors de la publication. Vous utiliseriez le nom d'exécution complet avec la commande, par exemple:
dnu publish --runtime dnx-clr-win-x86.1.0.0-rc1
Pour dotnet
:
Vous n'avez pas besoin de spécifier les versions d'exécution ou de framework - par défaut, dotnet publish
utilisera le framework de project.json
et la version d'exécution actuelle. Cependant, le documentation indique que:
la commande dotnet-publish nécessite également certaines dépendances dans project.json pour fonctionner. A savoir le package Microsoft.NETCore.Runtime doit être référencé en tant que dépendance pour que la commande copie les fichiers d'exécution ainsi que les fichiers de l'application vers l'emplacement publié .