.NET Core vs Mono

Question

Quelle est la différence entre .NET Core et Mono?

J'ai trouvé une déclaration sur le site officiel qui disait: "Le code écrit pour elle est également portable sur différentes piles d'applications, telles que Mono."

Mon objectif est d'utiliser C#, LINQ, EF7 et Visual Studio pour créer un site web qui peut être exécuté/hébergé sur Linux.

Quelqu'un m'a dit qu'il voulait que ce soit "en Mono", mais je ne sais pas ce que cela signifie. Je sais que je veux utiliser le .NET Core 1.0 avec les technologies que j'ai mentionnées ci-dessus. Il a également dit qu'il voulait utiliser "fast CGI". Je ne sais pas ce que cela signifie non plus.

Pouvez-vous m'aider à comprendre tous ces termes et si mes attentes sont réalistes?

Answer 1

Nécromancie.
Fournir une réponse réelle.

Quelle est la différence entre .Net Core et Mono ?

.NET Core est désormais officiellement l'avenir de .NET. Cela a commencé en grande partie par une réécriture de l'architecture ASP.NET MVC et les applications console, ce qui inclut bien sûr les applications serveur. (Puisqu'il est complet au sens de Turing et qu'il supporte l'interopérabilité avec les dlls C, vous pouvez, si vous le voulez absolument, écrire vos propres applications de bureau avec lui, par exemple par le biais de bibliothèques tierces telles que Avalonia qui étaient un peu très basiques à l'époque où j'ai écrit ceci, ce qui signifiait que vous étiez à peu près limité à des trucs web ou serveur). Au fil du temps, de nombreuses API ont été ajoutées à .NET Core, à tel point qu'après la version 3.1, .NET Core passera à la version 5.0, qui sera connue sous le nom de .NET 5.0 sans le "Core", et qui constituera alors l'avenir du .NET Framework. Ce qui était auparavant le .NET Framework complet restera en mode maintenance sous le nom de Full .NET Framework 4.8.x pendant quelques décennies, jusqu'à sa mort (il y aura peut-être encore des mises à jour, mais j'en doute). En d'autres termes, .NET Core est l'avenir de .NET, et le Full .NET Framework disparaîtra comme le Dodo/Silverlight/WindowsPhone. .

L'objectif principal de .NET Core, en dehors de la prise en charge multiplateforme, est d'améliorer les performances et de permettre la "compilation native"/le déploiement autonome (de sorte que vous n'avez pas besoin d'installer .NET framework/VM sur la machine cible).
D'une part, cela signifie la prise en charge de docker.io sous Linux, et d'autre part, le déploiement autonome est utile dans le "cloud computing", car vous pouvez alors utiliser la version du framework dotnet-CORE que vous souhaitez, sans avoir à vous soucier de la ou des versions du framework .NET que l'administrateur système a réellement installées.

Si le moteur d'exécution .NET Core prend en charge plusieurs systèmes d'exploitation et processeurs, le SDK est une autre histoire. Et si le SDK prend en charge plusieurs systèmes d'exploitation, la prise en charge d'ARM pour le SDK est/était toujours en cours. .NET Core est soutenu par Microsoft. Dotnet-Core n'a pas été livré avec WinForms ou WPF ou quoi que ce soit d'autre.

• À partir de la version 3.0, WinForms et WPF sont également pris en charge par .NET Core, mais uniquement sur Windows, et uniquement par C#. Pas par VB.NET (La prise en charge de VB.NET est prévue pour la v5 en 2020). Et il n'y a pas de Forms Designer dans .NET Core : il sera livré avec une mise à jour de Visual Studio plus tard, à une date non précisée.
• Les WebForms ne sont toujours pas pris en charge par .NET Core, et il n'est pas prévu de les soutenir, jamais. ( Blazor est le nouvel enfant en ville pour cela).
• .NET Core est également livré avec System.Runtime, qui remplace mscorelib.
• Souvent, .NET Core est confondu avec NetStandard Il s'agit d'une sorte d'enveloppe autour de System.Runtime/mscorelib (et d'autres), qui vous permet d'écrire des bibliothèques qui ciblent .NET Core, Full .NET Framework et Xamarin (iOS/Android), en même temps.
• le SDK .NET Core ne fonctionne pas/ne fonctionnait pas sur ARM, du moins pas la dernière fois que j'ai vérifié.

" Le Mono Projet" est beaucoup plus ancien que .NET Core.
Mono est un mot espagnol qui signifie "singe". Soit dit en passant, le nom n'a rien à voir avec la mononucléose (indice : vous pourriez obtenir une liste du personnel dans le cadre du programme "Mono"). http://primates.ximian.com /).
Mono a été lancé en 2005 par Miguel de Icaza (le gars qui a commencé GNOME - et quelques autres) comme une implémentation du .NET Framework pour Linux (Ximian/SuSe/Novell). Mono inclut Web-Forms, Winforms, MVC, Olive, et un IDE appelé MonoDevelop (également connu sous le nom de Xamarin Studio ou Visual Studio Mac). Il s'agit essentiellement de l'équivalent de (OpenJDK) JVM et (OpenJDK) JDK/JRE (par opposition à SUN/Oracle JDK). Vous pouvez l'utiliser pour faire fonctionner des applications ASP.NET-WebForms + WinForms + ASP.NET-MVC sur Linux.

Mono est pris en charge par Xamarin (le nouveau nom de la société qui s'appelait auparavant Ximian, lorsqu'elle se concentrait sur le marché des téléphones portables plutôt que sur celui de Linux), et non par Microsoft.
(depuis que Xamarin a été racheté par Microsoft, c'est techniquement [mais pas culturellement] Microsoft).
Vous obtiendrez généralement la compilation de votre matériel C# sur mono, mais pas celle de votre matériel VB.NET.
Il manque à Mono certaines fonctionnalités avancées, comme WSE/WCF et WebParts.
De nombreuses implémentations Mono sont incomplètes (par exemple, lancer NotImplementedException dans le cryptage ECDSA), boguées (par exemple, ODBC/ADO.NET avec Firebird), se comportent différemment de .NET (par exemple, la sérialisation XML) ou sont instables (ASP.NET MVC) et d'une lenteur inacceptable (Regex). Le bon côté des choses, c'est que la chaîne d'outils Mono fonctionne également sur ARM.

En ce qui concerne .NET Core, quand ils disent multiplateforme, ne vous attendez pas à ce que cela signifie que vous pouvez simplement installer .NET Core sous ARM-Linux, comme vous pouvez le faire avec ElasticSearch. Vous devrez compiler l'ensemble du framework à partir des sources.
Si vous disposez de cet espace (par exemple, sur un Chromebook, dont le disque dur total est de 16 à 32 Go).
Il avait également des problèmes d'incompatibilité avec OpenSSL 1.1 et libcurl.
Ces problèmes ont été corrigés dans la dernière version de .NET Core Version 2.2.
Tant pis pour le multiplateforme.

J'ai trouvé une déclaration sur le site officiel qui dit : "Le code écrit pour est également portable à travers les piles d'applications, telles que Mono".

Tant que ce code ne repose pas sur des appels WinAPI, des pinvokes Windows-dll, des composants COM, un système de fichiers insensible à la casse, l'encodage système par défaut (codepage) et qu'il n'a pas de problèmes de séparateur de répertoire, c'est correct. Cependant, le code .NET Core s'exécute sur .NET Core, et non sur Mono. Il sera donc difficile de mélanger les deux. Et comme Mono est assez instable et lent (pour les applications web), je ne le recommanderais pas de toute façon. Essayez le traitement d'image sur .NET Core, par exemple WebP ou le déplacement de GIF ou multipage-tiff ou l'écriture de texte sur une image, vous serez méchamment surpris.

Note :
Depuis .NET Core 2.0, il existe System.Drawing.Common (NuGet), qui contient la plupart des fonctionnalités de System.Drawing. contient la plupart des fonctionnalités de System.Drawing. Il devrait être plus ou moins complet dans .NET-Core 2.1. Cependant, System.Drawing.Common utilise GDI+, et ne fonctionnera donc pas sur Azure. (Les bibliothèques System.Drawing sont disponibles dans Azure Cloud Service [en fait juste une VM], mais pas dans Azure Web App [en fait de l'hébergement partagé ? hébergement partagé])
Jusqu'à présent, System.Drawing.Common fonctionne bien sur Linux/Mac, mais a des problèmes sur iOS/Android - s'il fonctionne du tout, là.
Avant .NET Core 2.0, c'est-à-dire vers la mi-février 2017, vous pouviez utiliser SkiaSharp pour l'imagerie (exemple) (vous pouvez toujours le faire).
Après .net-core 2.0, vous remarquerez que SixLabors ImageSharp est la meilleure solution, car System.Drawing n'est pas nécessairement sûr et présente de nombreuses fuites de mémoire potentielles ou réelles, ce qui explique pourquoi vous ne devriez pas utiliser GDI dans les applications Web. Notez que SkiaSharp est beaucoup plus rapide qu'ImageSharp, car il utilise des bibliothèques natives (ce qui peut aussi être un inconvénient). Notez également que si GDI+ fonctionne sur Linux et Mac, cela ne signifie pas qu'il fonctionne sur iOS/Android.

Le code non écrit pour .NET (non-Core) n'est pas portable vers .NET Core.
Autrement dit, si vous voulez une bibliothèque C# non GPL comme PDFSharp pour créer des documents PDF (très courant), vous n'avez pas de chance. (pour l'instant) ( plus maintenant ). Peu importe le contrôle ReportViewer, qui utilise Windows-pInvokes (pour crypter, créer des documents mcdf via COM, et pour obtenir des informations sur les polices, les caractères, le crénage, l'intégration des polices, mesurer les chaînes de caractères et faire des sauts de ligne, et pour dessiner réellement des tiffs de qualité acceptable), et qui ne fonctionne même pas sous Mono sous Linux.
( Je travaille là-dessus. ).

En outre, le code écrit en .NET Core n'est pas portable vers Mono, car Mono ne dispose pas des bibliothèques d'exécution de .NET Core (jusqu'à présent).

Mon objectif est d'utiliser C#, LINQ, EF7, visual studio pour créer un site web qui peut être exécuté / hébergé dans linux.

EF, dans toutes les versions que j'ai essayées jusqu'à présent, était tellement lent (même pour des choses aussi simples qu'une table avec une jointure à gauche) que je ne le recommanderais jamais - pas sous Windows non plus.
Je déconseille particulièrement EF si vous avez une base de données avec des contraintes uniques, ou des colonnes varbinaires/filestream/hierarchyid. (Pas non plus pour la mise à jour des schémas).
Et pas non plus dans une situation où la performance de la base de données est critique (disons 10+ à 100+ utilisateurs simultanés).
De plus, l'exécution d'un site web ou d'une application web sous Linux implique tôt ou tard que vous devrez le déboguer.
Il n'existe pas de support de débogage pour .NET Core sous Linux. (Plus maintenant, mais nécessite JetBrains Rider.)
MonoDevelop ne supporte pas (encore) le débogage des projets .NET Core.
Si vous avez des problèmes, vous vous débrouillez tout seul. Vous devrez utiliser la journalisation extensive.
Attention, une journalisation extensive remplira votre disque en un rien de temps, en particulier si votre programme entre dans une boucle infinie ou une récursion.
C'est particulièrement dangereux si votre application web s'exécute en tant que Root, car la connexion requiert de l'espace dans le fichier de connexion - s'il n'y a plus d'espace libre, vous ne pourrez plus vous connecter.
(Normalement, environ 5 % de l'espace disque est réservé à l'utilisateur Root [alias administrateur sous Windows], de sorte qu'au moins l'administrateur peut encore se connecter si le disque est presque plein. Mais si vos applications s'exécutent en tant que Root, cette restriction ne s'applique pas à leur utilisation du disque, et leurs fichiers journaux peuvent donc utiliser 100% de l'espace libre restant, de sorte que même l'administrateur ne peut plus se connecter).
Il est donc préférable de ne pas chiffrer ce disque, c'est-à-dire si vous tenez à vos données/système.

Quelqu'un m'a dit qu'il voulait que ce soit "en Mono", mais je ne sais pas ce que cela signifie.

Cela signifie soit qu'il ne veut pas utiliser .NET Core, soit qu'il veut simplement utiliser C# sur Linux/Mac. Je pense qu'il veut juste utiliser C# pour une application Web sur Linux. .NET Core est la voie à suivre pour cela, si vous voulez absolument le faire en C#. N'optez pas pour "Mono proprement dit" ; en apparence, cela semble fonctionner au début - mais croyez-moi, vous le regretterez car l'ASP.NET MVC de Mono n'est pas stable lorsque votre serveur fonctionne à long terme (plus d'un jour) - vous êtes maintenant prévenu. Voir aussi les références "did not complete" lors de la mesure des performances de Mono sur les benchmarks techempower.

Je sais que je veux utiliser le framework .Net Core 1.0 avec les technologies que j'ai énumérées ci-dessus. Il a également dit qu'il voulait utiliser "fast cgi". Je ne sais pas non plus ce que cela signifie non plus.

Cela signifie qu'il veut utiliser un serveur Web performant et complet comme nginx (Engine-X), voire Apache.
Il peut alors faire fonctionner mono/dotnetCore avec un hébergement basé sur des noms virtuels (plusieurs noms de domaine sur la même IP) et/ou un équilibrage de charge. Il peut également faire fonctionner d'autres sites web avec d'autres technologies, sans avoir besoin d'un numéro de port différent sur le serveur web. Cela signifie que votre site Web fonctionne sur un serveur fastcgi et que nginx fait suivre toutes les requêtes Web pour un certain domaine via le protocole fastcgi vers ce serveur. Cela signifie également que votre site Web fonctionne dans un pipeline fastcgi, et que vous devez faire attention à ce que vous faites, par exemple, vous ne pouvez pas utiliser HTTP 1.1 pour transmettre des fichiers.
Sinon, les fichiers seront brouillés à la destination.
Voir aussi ici et ici .

Pour conclure :
.NET Core à l'heure actuelle (2016-09-28) n'est pas vraiment portable, ni vraiment multiplateforme (en particulier les outils de débogage).
La compilation native n'est pas non plus facile, en particulier pour les systèmes ARM.
Et pour moi, il ne semble pas non plus que son développement soit "vraiment terminé", pour le moment.
Par exemple, System.Data.DataTable/DataAdaper.Update est absent... (plus avec .NET Core 2.0)
Avec les interfaces System.Data.Common.IDB*. (plus avec .NET Core 1.1)
s'il y a une classe qui est souvent utilisée, DataTable/DataAdapter serait celle-là...
De même, l'installateur Linux (.deb) échoue, du moins sur ma machine, et je suis sûr que je ne suis pas le seul à avoir ce problème.
Déboguer, peut-être avec Visual Studio Code, si vous pouvez le construire sur ARM (j'ai réussi à le faire). ne suivez PAS l'article du blog de Scott Hanselman si vous faites cela. - il y a un howto dans le wiki de VS-Code sur github), car ils ne proposent pas l'exécutable.
Yeoman échoue également. (Je suppose que cela a quelque chose à voir avec la version de nodejs que vous avez installée - VS Code requiert une version, Yeoman une autre... mais ils devraient fonctionner sur le même ordinateur. assez boiteux
Peu importe qu'il doive fonctionner sur la version du nœud livrée par défaut sur le système d'exploitation.
Peu importe qu'il ne devrait pas y avoir de dépendance à NodeJS en premier lieu.
Le serveur kestell est également en cours de réalisation.
Et à en juger par mon expérience avec le projet mono, je doute fortement qu'ils aient jamais testé .NET Core sur FastCGI, ou qu'ils aient la moindre idée de ce que le support FastCGI signifie pour leur framework, sans parler du fait qu'ils l'ont testé pour s'assurer que "tout fonctionne". En fait, je viens d'essayer de faire une application fastcgi-avec .NET Core et je viens de réaliser qu'il n'y a pas de bibliothèque FastCGI pour .NET Core "RTM"...

Donc, si vous voulez exécuter .NET Core "RTM" derrière nginx, vous ne pouvez le faire qu'en envoyant les requêtes à kestrell (ce serveur web dérivé de nodeJS semi-fini) - il n'y a pas de support fastcgi pour le moment dans .NET Core "RTM", AFAIK. Puisqu'il n'y a pas de bibliothèque fastcgi dans .NET Core, ni d'échantillons, il est également très peu probable que quelqu'un ait effectué des tests sur le framework pour s'assurer que fastcgi fonctionne comme prévu.

Je m'interroge également sur les performances.
Dans le (préliminaire) techempower-benchmark (round 13) En ce qui concerne la sérialisation JSON, aspnetcore-linux se classe à 25 % des meilleures performances, tandis que des frameworks comparables comme Go (golang) se classent à 96,9 % des performances maximales (et ce, en retournant du texte en clair sans accès au système de fichiers uniquement). .NET Core fait un peu mieux en matière de sérialisation JSON, mais cela ne semble pas convaincant non plus (Go atteint 98,5 % des performances maximales, .NET Core 65 %). Cela dit, il est impossible que ce soit pire que "mono proper".

De plus, étant donné qu'il est encore relativement récent, les principales bibliothèques n'ont pas toutes été portées (encore), et je doute que certaines d'entre elles le soient un jour.
La prise en charge de l'imagerie est également discutable, au mieux.
Pour tout ce qui est cryptage, utilisez plutôt BouncyCastle.

Pouvez-vous m'aider à comprendre tous ces termes ? et si mes attentes sont réalistes ?

J'espère que je vous ai aidé à donner plus de sens à tous ces termes.
En ce qui concerne vos attentes :
Développer une application Linux sans rien connaître à Linux est une idée vraiment stupide, et c'est aussi voué à l'échec d'une manière ou d'une autre. Cela dit, comme Linux n'entraîne aucun coût de licence, c'est une bonne idée en principe, MAIS SEULEMENT SI VOUS SAVEZ CE QUE VOUS FAITES.
Développer une application pour une plateforme sur laquelle vous ne pouvez pas déboguer votre application est une autre très mauvaise idée.
Développer pour fastcgi sans connaître les conséquences est encore une autre très mauvaise idée.

Faire toutes ces choses sur une plateforme "expérimentale" sans aucune connaissance des spécificités de cette plateforme et sans support de débogage est du suicide, si votre projet est plus qu'une page d'accueil personnelle. D'un autre côté, je suppose que le faire avec votre page d'accueil personnelle à des fins d'apprentissage serait probablement une très bonne expérience - alors vous apprenez à connaître le cadre et les problèmes non liés au cadre.
Vous pouvez par exemple (par programmation) monter en boucle un fat32, hfs ou JFS insensible à la casse pour votre application, afin de contourner les problèmes de sensibilité à la casse (montage en boucle non recommandé en production).

Pour résumer
À l'heure actuelle (2016-09-28), je me tiendrais à l'écart de .NET Core (pour une utilisation en production). Peut-être que dans un à deux ans, vous pourrez jeter un autre coup d'œil, mais probablement pas avant.
Si vous développez un nouveau projet web, démarrez-le en .NET Core, pas en mono.

Si vous voulez un framework qui fonctionne sur Linux (x86/AMD64/ARMhf) et Windows et Mac, qui n'a aucune dépendance, c'est-à-dire uniquement des liens statiques et aucune dépendance vis-à-vis de .NET, Java ou Windows, utilisez plutôt Golang. Il est plus mature, et ses performances sont prouvées (Baidu l'utilise avec 1 million d'utilisateurs simultanés), et golang a une empreinte mémoire nettement inférieure. De plus, golang est dans les dépôts, le .deb s'installe sans problème, le code source se compile - sans nécessiter de modifications - et golang (en attendant) a un support de débogage avec delve et JetBrains. Gogland sur Linux (et Windows et Mac). Le processus de construction (et le runtime) de Golang ne dépend pas non plus de NodeJS, ce qui est un autre avantage.

Pour ce qui est de la mono, n'y touchez pas.
Il est tout à fait étonnant de constater les progrès réalisés par le mono, mais malheureusement, cela ne remplace pas ses problèmes de performance, d'évolutivité et de stabilité pour les applications de production.
De plus, le mono-développement n'existe plus. Ils ne développent plus que les parties pertinentes pour Android et iOS, car c'est là que Xamarin gagne de l'argent.
Ne vous attendez pas à ce que le développement Web soit un citoyen de première classe de Xamarin/mono.
.NET Core peut en valoir la peine si vous démarrez un nouveau projet, mais pour les grands projets de formulaires Web existants, le portage est largement hors de question, les changements requis étant énormes. Si vous avez un projet MVC, la quantité de changements pourrait être gérable, si la conception de votre application originale était saine, ce qui n'est généralement pas le cas pour la plupart des applications existantes dites "historiquement développées".

Mise à jour de décembre 2016 :
La compilation native a été retirée de l'aperçu de .NET Core, car elle n'est pas encore prête...

Il semble qu'ils aient beaucoup amélioré le benchmark du fichier texte brut, mais d'un autre côté, il est devenu assez bogué. De même, il s'est encore détérioré dans les benchmarks JSON. Curieux aussi que le framework entity soit plus rapide pour les mises à jour que Dapper - bien que les deux soient à une lenteur record. Il est très peu probable que cela soit vrai. Il semble qu'il y ait encore plus que quelques bogues à chasser.

De plus, il semble qu'il y ait un soulagement sur le front des IDE Linux.
JetBrains a publié "Project Rider", un aperçu en accès anticipé d'un IDE C#/.NET Core pour Linux (et Mac et Windows), qui peut gérer les fichiers Visual Studio Project. Enfin un IDE C# qui est utilisable et qui n'est pas lent comme l'enfer.

Conclusion : .NET Core est toujours un logiciel de qualité en préversion, alors que nous entrons dans l'année 2017. Portez vos bibliothèques, mais ne l'utilisez pas en production, jusqu'à ce que la qualité du framework se stabilise.
Et gardez un œil sur le projet Rider.

Mise à jour de 2017
J'ai migré ma page d'accueil (celle de mon frère) vers .NET Core pour le moment.
Jusqu'à présent, le runtime sur Linux semble être suffisamment stable (au moins pour les petits projets) - il a survécu à un test de charge avec facilité - mono ne l'a jamais fait.
De plus, il semble que j'ai confondu .NET-Core-native et .NET-Core-self-contained-deployment. Le déploiement autonome fonctionne, mais il est un peu sous-documenté, bien qu'il soit super facile (les outils de construction et de publication sont encore un peu instables - si vous rencontrez "Positive number required. - Build FAILED." - exécutez à nouveau la même commande, et ça marche).

Vous pouvez exécuter

dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64

Remarque : selon .NET Core 3, vous pouvez publier tout ce que vous voulez. minifié en tant que fichier unique :

dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true

Cependant, contrairement à go, il ne s'agit pas d'un exécutable lié statiquement, mais d'un fichier zip auto-extractible. problèmes, en particulier si le répertoire temporaire est verrouillé par une de groupe, ou d'autres questions . Ça marche bien pour un programme "hello-world", cependant. Et si vous ne réduisez pas la taille de l'exécutable, elle atteindra environ 100 Mo.

Et vous obtenez un fichier .exe autonome (dans le répertoire de publication), que vous pouvez déplacer sur une machine Windows 8.1 sans .NET framework installé et le laisser fonctionner. C'est bien. C'est ici que dotNET-Core commence à devenir intéressant. (attention aux écarts, SkiaSharp ne fonctionne pas sous Windows 8.1 / Mais il est intéressant de noter que la défaillance de Skia-dll-load ne fait pas planter l'ensemble du serveur/de l'application et que tout le reste fonctionne).

(Note : Il manque à SkiaSharp sous Windows 8.1 les fichiers d'exécution VC appropriés - msvcp140.dll et vcruntime140.dll. Copiez-les dans le répertoire de publication, et Skia fonctionnera sous Windows 8.1).

Mise à jour d'août 2017
Sortie de .NET Core 2.0.
Faites attention - cela s'accompagne de changements (énormes) dans l'authentification...
Le bon côté des choses, c'est qu'elle a ramené les classes DataTable/DataAdaper/DataSet, et bien d'autres encore.
Je me suis rendu compte que .NET Core ne prend toujours pas en charge Apache SparkSQL, car Mobius n'est pas encore porté. C'est mauvais, car cela signifie qu'il n'y a pas de support SparkSQL pour mon cluster Cassandra IoT, donc pas de jointures...
Support ARM expérimental (runtime uniquement, pas de SDK - dommage pour le travail de développement sur mon Chromebook - j'attends avec impatience la version 2.1 ou 3.0).
PdfSharp est maintenant porté à titre expérimental vers .NET Core.
Cavalier JetBrains a quitté EAP. Vous pouvez maintenant l'utiliser pour développer et déboguer .NET Core sur Linux - bien que pour l'instant, seulement .NET Core 1.1 jusqu'à ce que la mise à jour pour le support de .NET Core 2.0 soit disponible.

Mise à jour de mai 2018
La version 2.1 de .NET Core est imminente. Peut-être que cela corrigera l'authentification NTLM sur Linux (l'authentification NTLM ne fonctionne pas sur Linux {et peut-être Mac} dans .NET-Core 2.0 avec des en-têtes d'authentification multiples, comme negotiate, communément envoyé avec ms-exchange, et apparemment ils ne le corrigent que dans la v2.1, pas de version de correction de bogue pour 2.0).
Mais je n'installe pas les versions préliminaires sur ma machine. J'attends donc.
La v2.1 est également censée réduire considérablement les temps de compilation. C'est une bonne chose.

Notez également que sous Linux, .NET Core est 64 bits uniquement !
Il n'y a pas, et il n'y aura pas, de version x86-32 de .NET Core sur Linux. .
Et le port ARM est uniquement ARM-32. Pas d'ARM-64, pour l'instant.
Et sur ARM, vous n'avez (pour l'instant) que le runtime, pas le dotnet-SDK.

Et encore une chose :
Parce que .NET-Core utilise OpenSSL 1.0, .NET Core sur Linux ne fonctionne pas sur Arch Linux, et par dérivation pas sur Manjaro (la distro Linux la plus populaire de loin à ce jour), car Arch Linux utilise OpenSSL 1.1. Donc si vous utilisez Arch Linux, vous n'avez pas de chance (avec Gentoo aussi).

Edit :

La dernière version de .NET Core 2.2+ supporte OpenSSL 1.1. Vous pouvez donc l'utiliser sur Arch ou (k)Ubuntu 19.04+. Vous devrez peut-être utiliser le .NET-Core installer script parce qu'il n'y a pas encore de paquets.

En revanche, les performances se sont nettement améliorées :

.NET Core 3 :
.NET-Core v 3.0 est censé apporter WinForms et WPF à .NET-Core.
Cependant, alors que WinForms et WPF seront des .NET-Core, WinForms et WPF en .NET-Core fonctionneront uniquement sur Windows, car WinForms/WPF utiliseront l'API Windows.

Note :
.NET Core 3.0 est maintenant disponible (RTM), et la prise en charge de WinForms et WPF est assurée, mais uniquement pour C# (sous Windows). Il y a pas de WinForms-Core-Designer . Le concepteur sera, éventuellement, livré avec une mise à jour de Visual Studio, un jour ou l'autre. Support WinForms pour VB.NET n'est pas pris en charge mais elle est prévue pour .NET 5.0 dans un avenir proche. 2020 .

PS :

echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1 

Si vous l'avez utilisé sous Windows, vous n'avez probablement jamais vu cela :

Les outils .NET Core collectent des données d'utilisation afin d'améliorer votre expérience.
Les données sont anonymes et ne comprennent pas les arguments de la ligne de commande. de commande.
Les données sont collectées par Microsoft et partagées avec la communauté.
Vous pouvez choisir de ne pas utiliser la télémétrie en définissant la variable d'environnement variable d'environnement DOTNET_CLI_TELEMETRY_OPTOUT à 1 en utilisant votre shell préféré.
Vous pouvez en savoir plus sur la télémétrie des outils .NET Core @ https://aka.ms/dotnet-cli-telemetry .

J'ai pensé mentionner que je pense que monodevelop (aka Xamarin Studio, l'IDE Mono, ou Visual Studio Mac comme il est maintenant appelé sur Mac) a évolué assez bien, et est - en attendant - largement utilisable.
Cependant, JetBrains Rider (2018 EAP à ce jour) est certainement beaucoup plus agréable et plus fiable (et le décompilateur inclus est une bouée de sauvetage), c'est-à-dire, si vous développez .NET-Core sur Linux ou Mac. MonoDevelop ne supporte pas Debug-StepThrough sur Linux dans .NET Core, cependant, puisque MS n'accorde pas de licence pour leur dll API de débogage (sauf pour VisualStudio Mac ... ). Cependant, vous pouvez utiliser la fonction Débogueur Samsung pour .NET Core à travers le Extension débogueur .NET Core pour Samsung Debugger pour MonoDevelop

Avis de non-responsabilité :
Je n'utilise pas de Mac, donc je ne peux pas dire si ce que j'ai écrit ici s'applique également aux Mac basés sur FreeBSD-Unix. Je fais référence à la version Linux (Debian/Ubuntu/Mint) de JetBrains Rider, mono, MonoDevelop/VisualStudioMac/XamarinStudio et .NET-Core. En outre, Apple envisage de passer des processeurs Intel aux processeurs ARM (ARM-64 ?) fabriqués par ses soins, de sorte que ce qui s'applique au Mac aujourd'hui pourrait ne plus s'appliquer au Mac à l'avenir (2020+).

Aussi, quand j'écris "mono est assez instable et lent", l'instable concerne les applications WinFroms & WebForms, spécifiquement l'exécution d'applications web via fastcgi ou avec XSP (sur la version 4.x de mono), ainsi que les particularités de la gestion de la sérialisation XML, et le très lent concerne WinForms, et les expressions régulières en particulier (ASP.NET-MVC utilise aussi les expressions régulières pour le routage).

Lorsque j'écris sur mon expérience de mono 2.x, 3.x et 4.x, cela ne signifie pas nécessairement que ces problèmes n'ont pas été résolus maintenant, ou au moment où vous lisez ceci, ni que s'ils sont corrigés maintenant, il ne peut y avoir une régression ultérieure qui réintroduit l'un de ces bogues/caractéristiques. Cela ne signifie pas non plus que si vous intégrez le runtime mono, vous obtiendrez les mêmes résultats que lorsque vous utilisez le runtime mono du système (dev). Cela ne signifie pas non plus que l'intégration du moteur d'exécution mono (n'importe où) est nécessairement gratuite.

Cela ne signifie pas nécessairement que mono est mal adapté à iOS ou Android, ou qu'il y a les mêmes problèmes. Je n'utilise pas mono sur Android ou IOS, donc je ne suis pas en mesure de dire quoi que ce soit sur la stabilité ou la facilité d'utilisation, coûts et les performances sur ces plateformes. Évidemment, si vous utilisez .NET sur Android, vous devez également prendre en compte d'autres coûts, comme la pondération des coûts de xamarin par rapport aux coûts et au temps nécessaires pour porter le code existant vers Java. On entend dire que mono sur Android et IOS sera assez bon. Prenez cela avec un grain de sel. D'une part, ne vous attendez pas à ce que l'encodage du système par défaut soit le même sur Android/ios que sur Windows, et ne vous attendez pas à ce que le système de fichiers Android soit insensible à la casse, et ne vous attendez pas à ce que les polices Windows soient présentes.

Answer 2

Dans le monde .NET, il existe deux types de CLR, les "complets" et les Core CLRs, et ce sont des choses assez différentes.

Il existe deux implémentations CLR "complètes", le CLR .NET natif de Microsoft (pour Windows) et le CLR Mono (qui lui-même a des implémentations pour Windows, linux et unix (Mac OS X et FreeBSD)). Un CLR complet est exactement cela - tout, à peu près, dont vous avez besoin. En tant que tel, les CLRs "complets" ont tendance à être de grande taille.

Les Core CLRs, en revanche, sont élagués et beaucoup plus petits. Parce qu'ils ne sont qu'une implémentation de base, il est peu probable qu'ils contiennent tout ce dont vous avez besoin, donc avec les Core CLRs, vous ajoutez des ensembles de fonctionnalités au CLR que votre produit logiciel spécifique utilise, en utilisant NuGet. Il existe des implémentations Core CLR pour Windows, linux (divers) et unix (Mac OS X et FreeBSD) dans le mix. Microsoft a ou est en train de refondre les bibliothèques du framework .NET pour Core CLR également, pour les rendre plus portables pour le contexte de base. Compte tenu de la présence de Mono sur les OS *nix, il serait surprenant que les Core CLRs pour *nix n'incluent pas une base de code mono, mais seule la communauté Mono et Microsoft pourrait nous le confirmer.

Aussi, je suis d'accord avec Nico pour dire que les Core CLRs sont nouveaux - il est à RC2 pour le moment, je crois. Je ne le recommanderais pas encore pour le code de production.

Pour répondre à votre question, vous pourriez livrer votre site sur linux en utilisant Core CLR ou Mono, et ce sont deux façons différentes de le faire. Si vous voulez une solution sûre pour l'instant, je choisirais Mono sur linux, puis je migrerais plus tard vers Core.

Answer 3

Vous avez choisi non seulement un chemin réaliste, mais probablement l'un des meilleurs écosystèmes fortement soutenu (également X-platforms) par MS. Cependant, vous devriez considérer les points suivants :

• Mise à jour : Le document principal sur la norme de la plate-forme .Net se trouve ici : https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
• Mise à jour : Le Mono actuel 4.4.1 ne peut pas exécuter le dernier Asp.Net core 1.0 RTM
• Bien que Mono soit plus complet en fonctionnalités, son avenir est incertain, car MS le possède depuis quelques mois maintenant et c'est un travail en double pour eux de le soutenir. Mais MS est définitivement engagé envers .Net Core et mise gros dessus.
• Bien que .Net Core soit publié, l'écosystème tiers n'est pas encore tout à fait prêt. Par exemple, Nhibernate, Umbraco, etc. ne peuvent pas encore fonctionner sous .Net Core. Mais ils ont un plan.
• Il y a certaines fonctionnalités manquantes dans .Net Core comme System.Drawing, vous devriez rechercher des bibliothèques tierces
• Vous devriez utiliser nginx comme serveur frontal avec kestrelserver pour les applications asp.net, car kestrelserver n'est pas tout à fait prêt pour la production. Par exemple, HTTP/2 n'est pas implémenté.

J'espère que cela vous aidera

Answer 4

.Net Core ne nécessite pas mono au sens du framework mono. .Net Core est un framework qui fonctionnera sur plusieurs plateformes, y compris Linux. Référence https://dotnet.github.io/.

Cependant, le .Net Core peut utiliser le framework mono. Référence https://docs.asp.net/en/1.0.0-rc1/getting-started/choosing-the-right-dotnet.html (note rc1 documentatiopn aucun rc2 disponible), cependant mono n'est pas un framework pris en charge par Microsoft et il est recommandé d'utiliser un framework pris en charge.

Maintenant, Entity Framework 7 est maintenant appelé Entity Framework Core et est disponible sur plusieurs plateformes, y compris Linux. Référence https://github.com/aspnet/EntityFramework (consultez la feuille de route)

Je suis actuellement en train d'utiliser ces deux frameworks, cependant vous devez comprendre qu'ils sont encore en stage de version candidate à la sortie (la version actuelle est RC2) et au fil des versions bêta et des versions candidate, il y a eu d'importants changements qui finissent généralement par vous laisser perplexe.

Voici un tutoriel sur comment installer MVC .Net Core sur Linux. https://docs.asp.net/en/1.0.0-rc1/getting-started/installing-on-linux.html

Enfin, vous avez le choix de serveurs Web (d'où je suppose que la référence à fast cgi vient) pour héberger votre application sur Linux. Voici un point de référence pour l'installation dans un environnement Linux. https://docs.asp.net/en/1.0.0-rc1/publishing/linuxproduction.html

Je réalise que ce post se termine principalement par des liens vers la documentation, mais à ce stade, ce sont vos meilleures sources d'informations. .Net Core est encore relativement nouveau dans la communauté .Net et jusqu'à sa sortie complète, je serais hésitant à l'utiliser dans un environnement de production étant donné les changements importants entre les versions publiées.

Answer 5

Cette question est particulièrement actuelle car hier Microsoft a officiellement annoncé la sortie de .NET Core 1.0. En supposant que Mono implémente la plupart des bibliothèques .NET standard, la différence entre Mono et .NET Core peut être vue à travers la différence entre .NET Framework et .NET Core:

• APIs — .NET Core contient bon nombre des mêmes, mais moins, APIs que le .NET Framework, et avec un formatage différent (les noms des assembly sont
  différents; la forme des types diffère dans des cas clés). Ces différences
  nécessitent actuellement généralement des modifications pour porter du code source vers .NET Core. .NET Core implémente l'API de la bibliothèque standard .NET, qui va s'accroître pour
  inclure davantage des APIs BCL du .NET Framework au fil du temps.
• Sous-systèmes — .NET Core implémente un sous-ensemble des sous-systèmes dans le .NET Framework, avec pour objectif une implémentation
  et un modèle de programmation plus simples. Par exemple, la Sécurité d'Accès au Code (CAS) n'est pas
  prise en charge, tandis que la réflexion est prise en charge.

Si vous avez besoin de lancer quelque chose rapidement, optez pour Mono car c'est actuellement (juin 2016) un produit plus mature, mais si vous construisez un site web sur le long terme, je vous suggère .NET Core. Il est officiellement pris en charge par Microsoft et la différence dans les APIs supportées disparaitra probablement bientôt, compte tenu de l'effort que Microsoft met dans le développement de .NET Core.

Mon objectif est d'utiliser C#, LINQ, EF7, Visual Studio pour créer un site web qui peut être exeécuté/hébergé sous Linux.

Linq et Entity Framework sont inclus dans .NET Core, donc vous pouvez y aller en toute sécurité.