Nécromancement.
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 du cadre ASP.NET MVC et des applications console, qui comprend bien sûr les applications serveur. (Étant donné qu'il est complet de Turing et prend en charge l'interopérabilité avec les DLL C, vous pouvez, si vous le souhaitez, également écrire vos propres applications de bureau avec, par exemple via des bibliothèques tierces comme Avalonia, qui étaient un peu très basiques au moment où j'ai écrit ceci, ce qui signifiait que vous étiez à peu près limité aux 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, sera connu sous le nom de .NET 5.0 sans le "Core", et ce sera alors l'avenir du .NET Framework. Ce qui était le .NET Framework complet restera en mode maintenance sous le nom de .NET Framework 4.8.x complet pendant quelques décennies, jusqu'à ce qu'il meure (il y aura peut-être encore des mises à niveau, mais j'en doute). En d'autres termes, .NET Core est l'avenir de .NET, et le .NET Framework complet suivra le chemin du Dodo / Silverlight / WindowsPhone .
Le point principal de .NET Core, en dehors de la prise en charge multiplateforme, est d'améliorer les performances et d'activer la «compilation native» / le déploiement autonome (vous n'avez donc pas besoin que le framework .NET / VM soit installé 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 simplement utiliser la version du framework dotnet-CORE que vous aimez, et vous n'avez pas à vous soucier des versions du framework .NET que l'administrateur système a réellement installées.
Alors que le runtime .NET Core prend en charge plusieurs systèmes d'exploitation et processeurs, le SDK est une autre histoire. Et bien que le SDK prenne en charge plusieurs systèmes d'exploitation, la prise en charge ARM du SDK est / était toujours en cours. .NET Core est pris en charge par Microsoft. Dotnet-Core n'est pas venu avec WinForms ou WPF ou quelque chose comme ça.
- À 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 (le support VB.NET est prévu pour la v5 en 2020). Et il n'y a pas de Concepteur de formulaires dans .NET Core: il est livré avec une mise à jour de Visual Studio plus tard, à une heure non spécifiée.
- Les formulaires Web ne sont toujours pas pris en charge par .NET Core, et il n'est pas prévu de les prendre en charge ( Blazor est le nouveau venu en ville pour cela).
- .NET Core est également fourni avec System.Runtime, qui remplace mscorelib.
- Souvent, .NET Core est mélangé avec NetStandard , qui est un peu un wrapper autour de System.Runtime / mscorelib (et quelques autres), qui vous permet d'écrire des bibliothèques qui ciblent .NET Core, Full .NET Framework et Xamarin (iOS / Android), tous en même temps.
- le SDK .NET Core ne fonctionne pas / n'a pas fonctionné sur ARM, du moins pas la dernière fois que j'ai vérifié.
"The Mono Project" est beaucoup plus ancien que .NET Core.
Mono est espagnol et signifie singe, et comme remarque secondaire, le nom n'a rien à voir avec la mononucléose (indice: vous pouvez obtenir une liste du personnel sous http://primates.ximian.com /).
Mono a été lancé en 2005 par Miguel de Icaza (le gars qui a lancé GNOME - et quelques autres) en tant qu'implémentation du .NET Framework pour Linux (Ximian / SuSe / Novell). Mono comprend des formulaires Web, Winforms, MVC, Olive et un IDE appelé MonoDevelop(également appelé Xamarin Studio ou Visual Studio Mac). Fondamentalement, l'équivalent de (OpenJDK) JVM et (OpenJDK) JDK / JRE (par opposition à SUN / Oracle JDK). Vous pouvez l'utiliser pour que les applications ASP.NET-WebForms + WinForms + ASP.NET-MVC fonctionnent sous Linux.
Mono est pris en charge par Xamarin (le nouveau nom de la société de ce qui était Ximian, lorsqu'ils se concentraient sur le marché mobile, au lieu du marché Linux), et non par Microsoft.
(puisque Xamarin a été acheté par Microsoft, c'est techniquement [mais pas culturellement] Microsoft.)
Vous obtiendrez généralement vos trucs C # à compiler en mono, mais pas les trucs VB.NET.
Mono manque certaines fonctionnalités avancées, comme WSE / WCF et WebParts.
De nombreuses implémentations Mono sont incomplètes (par exemple, lançent NotImplementedException dans le cryptage ECDSA), boguées (par exemple ODBC / ADO.NET avec Firebird), se comportent différemment que sur .NET (par exemple la sérialisation XML) ou autrement instables (ASP.NET MVC) et d'une lenteur inacceptable (Regex). À la hausse, 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 multiplateforme signifie que vous pourriez en fait simplement installer apt. Get Core sur ARM-Linux, comme vous pouvez le faire avec ElasticSearch. Vous devrez compiler l'intégralité du framework à partir des sources.
Autrement dit, si vous avez cet espace (par exemple sur un Chromebook, qui a une HD totale de 16 à 32 Go).
Il avait également des problèmes d'incompatibilité avec OpenSSL 1.1 et libcurl.
Celles-ci ont été corrigées dans la dernière version de .NET Core version 2.2.
Voilà pour multiplateforme.
J'ai trouvé une déclaration sur le site officiel qui disait: "Le code écrit pour lui est également portable sur plusieurs piles d'applications, comme Mono".
Tant que ce code ne repose pas sur les appels WinAPI, Windows-dll-pinvokes, COM-Components, un système de fichiers insensible à la casse, le codage par défaut du système (page de codes) et n'a pas de problèmes de séparateur de répertoires, 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.
Remarque:
À partir de .NET Core 2.0, il existe System.Drawing.Common (NuGet), qui 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 donc ne fonctionnera pas sur Azure (bibliothèques System.Drawing sont disponibles dans Azure Cloud Service [fondamentalement juste une machine virtuelle], mais pas dans Azure Web App [essentiellement hébergement partagé?])
Ainsi , loin, System.Drawing.Common fonctionne bien sur Linux / Mac, mais a des problèmes sur iOS / Android - si cela fonctionne, là-bas.
Avant .NET Core 2.0, c'est-à-dire mi-février 2017, vous pouviez utiliser SkiaSharp pour l'imagerie (exemple) (vous pouvez toujours).
Après .net-core 2.0, vous remarquerez que SixLabors ImageSharpest le chemin à parcourir, car System.Drawing n'est pas nécessairement sécurisé et a beaucoup de fuites de mémoire potentielles ou réelles, c'est pourquoi vous ne devriez pas utiliser GDI dans les applications Web; Notez que SkiaSharp est beaucoup plus rapide que ImageSharp, car il utilise des bibliothèques natives (ce qui peut également être un inconvénient). Notez également que bien que 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 pour .NET Core.
Autrement dit, si vous voulez qu'une bibliothèque non GPL C # comme PDFSharp crée des documents PDF (très courant), vous n'avez pas de chance(en ce moment)( 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 la police, les caractères, le crénage, l'incorporation de polices, mesurer les chaînes et faire des sauts de ligne, et pour dessiner des tiffs de qualité acceptable) , et ne fonctionne même pas sur Mono sous Linux
( j'y travaille ).
En outre, le code écrit en .NET Core n'est pas portable pour Mono, car Mono n'a pas les bibliothèques d'exécution .NET Core (jusqu'à présent).
Mon objectif est d'utiliser C #, LINQ, EF7, Visual Studio pour créer un site Web pouvant être exécuté / hébergé sous Linux.
EF dans n'importe quelle version que j'ai essayée jusqu'à présent était si sacrément lent (même sur des choses aussi simples comme une table avec une jointure gauche), je ne le recommanderais jamais - pas sur Windows non plus.
Je ne recommanderais pas particulièrement EF si vous avez une base de données avec des contraintes uniques ou des colonnes varbinary / filestream / hierarchyid. (Pas pour la mise à jour du schéma non plus.)
Et pas non plus dans une situation où les performances de base de données sont critiques (disons 10+ à 100+ utilisateurs simultanés).
En outre, exécuter un site Web / une application Web sous Linux signifie tôt ou tard que vous devrez le déboguer.
Il n'y a pas de prise en charge du débogage pour .NET Core sous Linux.(Plus maintenant, mais nécessite JetBrains Rider.)
MonoDevelop ne prend pas (encore) en charge le débogage des projets .NET Core.
Si vous avez des problèmes, vous êtes seul. Vous devrez utiliser une journalisation étendue.
Soyez prudent, sachez qu'une journalisation étendue remplira votre disque en un rien de temps, en particulier si votre programme entre dans une boucle infinie ou récursive.
(Normalement, environ 5% de l'espace disque est réservé à l'utilisateur root [aka administrateur sur Windows], donc au moins l'administrateur peut toujours 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 pour leur utilisation du disque, et ainsi leurs fichiers journaux peuvent utiliser 100% de l'espace libre restant, donc même l'administrateur ne peut plus se connecter.)
Cela est particulièrement dangereux si votre application Web s'exécute en tant que root, car la connexion nécessite un espace de fichier journal - s'il n'y a plus d'espace libre, vous ne pourrez plus vous connecter.
Il est donc préférable de ne pas crypter ce disque, c'est-à-dire si vous appréciez 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 qu'il ne veut pas utiliser .NET Core, ou qu'il veut simplement utiliser C # sur Linux / Mac. Je suppose qu'il veut juste utiliser C # pour une Web-App sur Linux. .NET Core est la voie à suivre pour cela, si vous voulez absolument le faire en C #. N'allez pas avec "Mono proprement dit"; en apparence, cela semble fonctionner au début - mais croyez-moi, vous le regretterez car ASP.NET MVC de Mono n'est pas stable lorsque votre serveur fonctionne à long terme (plus d'un jour) - vous avez maintenant été averti. Voir également les références «n'a pas terminé» lors de la mesure des performances 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 des "cgi rapides". Je ne sais pas non plus ce que cela signifie.
Cela signifie qu'il veut utiliser un serveur Web complet et performant comme nginx (Engine-X), peut-être Apache.
Ensuite, il peut exécuter mono / dotnetCore avec un hébergement basé sur un nom virtuel (plusieurs noms de domaine sur la même IP) et / ou un équilibrage de charge. Il peut également exécuter 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 s'exécute sur un serveur fastcgi, et nginx transmet toutes les demandes Web pour un certain domaine via le protocole fastcgi à ce serveur. Cela signifie également que votre site Web s'exécute dans un pipeline fastcgi, et vous devez faire attention à ce que vous faites, par exemple, vous ne pouvez pas utiliser HTTP 1.1 lors de la transmission de fichiers.
Sinon, les fichiers seront tronqué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 ARM.
Et pour moi, il ne semble pas non plus que son développement soit "vraiment terminé".
Par exemple, System.Data.DataTable / DataAdaper.Update est manquant ...
(plus avec .NET Core 2.0)
Avec les interfaces System.Data.Common.IDB *.(plus avec .NET Core 1.1)
s'il y a jamais eu une classe qui est souvent utilisée, DataTable / DataAdapter le serait ...
De plus, l'installateur Linux (.deb) échoue, au moins sur ma machine, et je ' 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 le blog de Scott Hanselman si vous le faites - il y a un howto dans le wiki de VS-Code sur github), parce que ils n'offrent 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 nécessite une version, Yeoman une autre ... mais il devrait fonctionner sur le même ordinateur. Assez boiteux
Peu importe qu'il devrait fonctionner sur la version de nœud livrée par défaut sur l'OS.
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 mono-projet, je doute fortement qu'ils aient jamais testé .NET Core sur FastCGI, ou qu'ils aient une idée de ce que le support FastCGI signifie pour leur framework, et encore moins qu'ils l'ont testé pour s'assurer que "tout fonctionne ". En fait, j'ai juste essayé de créer 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, lorsque vous allez exécuter .NET Core "RTM" derrière nginx, vous ne pouvez le faire qu'en envoyant des requêtes par proxy à Kestrell (ce serveur Web semi-fini dérivé de nodeJS) - il n'y a pas de support fastcgi actuellement dans .NET Core "RTM", AFAIK. Comme il n'y a pas de bibliothèque fastcgi de base .net et aucun échantillon, il est également très peu probable que quelqu'un ait fait des tests sur le framework pour s'assurer que fastcgi fonctionne comme prévu.
Je remets également en question la performance.
Dans le benchmark (préliminaire) techempower (round 13) , aspnetcore-linux se classe à 25% par rapport aux meilleures performances, tandis que des cadres comparables comme Go (golang) se classent à 96,9% des performances de pointe (et c'est lors du retour de texte en clair sans fichier - accès système uniquement). .NET Core fait un peu mieux sur la sérialisation JSON, mais il ne semble pas non plus convaincant (aller atteint 98,5% du pic, .NET core 65%). Cela dit, cela ne peut pas être pire que "mono proprement dit".
De plus, comme il est encore relativement nouveau, toutes les bibliothèques principales n'ont pas (encore) été portées, et je doute que certaines d'entre elles le seront jamais.
Le support d'imagerie est également au mieux discutable.
Pour tout chiffrement, utilisez plutôt BouncyCastle.
Pouvez-vous m'aider à donner un sens à 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 savoir de Linux est une idée vraiment stupide en premier lieu, et elle est également vouée à l'échec d'une manière ou d'une autre horrible. Cela dit, parce que Linux ne coûte pas 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 plate-forme sur laquelle vous ne pouvez pas déboguer votre application est une autre très mauvaise idée.
Développer pour fastcgi sans savoir quelles conséquences il y a est encore une très mauvaise idée.
Faire toutes ces choses sur une plate-forme "expérimentale" sans aucune connaissance des spécificités de cette plate-forme et sans support de débogage est un suicide, si votre projet est plus qu'une simple 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 - vous apprendrez alors quel est le cadre et quels sont 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, pour contourner les problèmes de respect de la casse (montage en boucle non recommandé en production).
Pour résumer
À l'heure actuelle (2016-09-28), je resterais loin de .NET Core (pour une utilisation en production). Peut-être que dans un à deux ans, vous pourrez revoir, mais probablement pas avant.
Si vous avez un nouveau projet Web que vous développez, démarrez-le dans .NET Core, pas mono.
Si vous voulez un framework qui fonctionne sous Linux (x86 / AMD64 / ARMhf) et Windows et Mac, qui n'a pas de dépendances, c'est-à-dire uniquement une liaison statique et aucune dépendance sur .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 considérablement plus faible. Aussi golang est dans les référentiels, le .deb s'installe sans problèmes, le code source se compile - sans nécessiter de modifications - et golang (en attendant) a un support de débogage avec delve et JetBrainsGogland sur Linux (et Windows et Mac). Le processus de construction (et l'exécution) de Golang ne dépend pas non plus de NodeJS, qui est encore un autre avantage.
En ce qui concerne le mono, éloignez-vous.
Le chemin parcouru par le mono est incroyable, mais malheureusement, cela ne remplace pas ses problèmes de performances / évolutivité et de stabilité pour les applications de production.
De plus, le mono-développement est assez mort, ils ne développent en grande partie 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 Xamarin / mono de première classe.
.NET Core peut 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 sont énormes. Si vous avez un projet MVC, la quantité de changements pourrait être gérable, si la conception de votre application d'origine était saine, ce qui n'est généralement pas le cas pour la plupart des applications dites «historiquement développées» existantes.
Mise à jour de décembre 2016: la
compilation native a été supprimée de l'aperçu .NET Core, car elle n'est pas encore prête ... Il
semble qu'ils se soient améliorés assez fortement par rapport au benchmark des fichiers texte bruts, mais d'un autre côté, c'est devenu assez bogué. En outre, il s'est encore détérioré dans les indices de référence JSON. Curieux également que le cadre d'entité soit plus rapide pour les mises à jour que Dapper - bien que les deux connaissent une lenteur record. Il est très peu probable que cela soit vrai. Il semble qu'il y ait encore plus que quelques bugs à chasser.
En outre, il semble y avoir un soulagement sur le front de l'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 de projet Visual Studio. Enfin un IDE C # qui est utilisable et qui n'est pas si lent que ça.
Conclusion: .NET Core est toujours un logiciel de qualité pré-version en mars 2017. Portez vos bibliothèques, mais éloignez-vous-en pour la production, jusqu'à ce que la qualité du framework se stabilise.
Et gardez un œil sur Project Rider.
Mise à jour 2017
J'ai migré la page d'accueil de mon (frère) vers .NET Core pour l'instant.
Jusqu'à présent, le temps d'exécution sur Linux semble être assez stable (au moins pour les petits projets) - il a facilement survécu à un test de charge - le mono n'a jamais réussi.
En outre, il semble que j'ai mélangé le déploiement natif .NET-Core et .NET-Core-self-CONTENU. Le déploiement autonome fonctionne, mais il est un peu sous-documenté, bien qu'il soit super facile (les outils de génération / publication sont un peu instables, pourtant - si vous rencontrez "Nombre positif requis. - Échec de la construction." - exécutez à nouveau la même commande, et il fonctionne).
Tu peux courir
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 qui est minifié dans un seul fichier :
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
Cependant, contrairement à go, ce n'est pas un exécutable lié statiquement, mais un fichier zip auto-extractible, donc lors du déploiement, vous pouvez rencontrer des problèmes, surtout si le répertoire temporaire est verrouillé par la stratégie de groupe ou d' autres problèmes . Fonctionne bien pour un programme bonjour, cependant. Et si vous ne réduisez pas la taille, la taille de l'exécutable sera d'environ 100 Mo.
Et vous obtenez un fichier .exe autonome (dans le répertoire de publication), que vous pouvez déplacer vers une machine Windows 8.1 sans framework .NET installé et le laisser s'exécuter. Agréable. C'est ici que dotNET-Core commence à devenir intéressant. (attention aux lacunes, SkiaSharp ne fonctionne pas sur Windows 8.1 / Windows Server 2012 R2, [encore] - l'écosystème doit d'abord rattraper son retard - mais il est intéressant de noter que Skia-dll-load-fail ne plante pas le serveur entier / application - donc tout le reste fonctionne)
(Remarque: SkiaSharp sur Windows 8.1 ne contient pas les fichiers d'exécution VC appropriés - msvcp140.dll et vcruntime140.dll. Copiez-les dans le répertoire de publication et Skia fonctionnera sur Windows 8.1.)
Mise à jour d'août 2017
.NET Core 2.0 publié.
Soyez prudent - vient avec (énorme rupture) des changements d'authentification ...
À la hausse, cela a ramené les classes DataTable / DataAdaper / DataSet, et bien d'autres.
Réalisé .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 prise en charge SparkSQL pour mon cluster IoT Cassandra, donc pas de jointures ...
Prise en charge expérimentale ARM (runtime uniquement, pas SDK - trop mauvais pour le développement sur mon Chromebook - avec impatience 2.1 ou 3.0).
PdfSharp est désormais porté expérimentalement vers .NET Core.
JetBrains Riderquitté EAP. Vous pouvez maintenant l'utiliser pour développer et déboguer .NET Core sous Linux - bien que jusqu'à présent, seulement .NET Core 1.1 jusqu'à ce que la mise à jour pour la prise en charge de .NET Core 2.0 soit en ligne.
Mise à jour de mai 2018
.NET Core 2.1 version imminente. Peut-être que cela corrigera l'authentification NTLM sur Linux (l'authentification NTLM ne fonctionne pas sur Linux {et éventuellement Mac} dans .NET-Core 2.0 avec plusieurs en-têtes d'authentification, tels que négociation, généralement envoyés avec ms-exchange, et ils sont apparemment ne le fixant que dans la v2.1, pas de version de correction de bugs pour 2.0).
Mais je n'installe pas de versions d'aperçu sur ma machine. Alors j'attends.
La v2.1 réduirait également considérablement les temps de compilation. Ce serait bien.
Notez également que sous Linux, .NET Core est uniquement en 64 bits !
Il n'y a pas et il n'y aura pas de version x86-32 de .NET Core sous Linux .
Et le port ARM est ARM-32 uniquement. Pas encore d'ARM-64.
Et sur ARM, vous n'avez (actuellement) que le runtime, pas le dotnet-SDK.
Et encore une chose:
parce que .NET-Core utilise OpenSSL 1.0, .NET Core sous Linux ne fonctionne pas sur Arch Linux, et par dérivation pas sur Manjaro (la distribution Linux la plus populaire de loin à ce stade), parce que Arch Linux utilise OpenSSL 1.1. Donc, si vous utilisez Arch Linux, vous n'avez pas de chance (avec Gentoo aussi).
Éditer:
La dernière version de .NET Core 2.2+ prend en charge OpenSSL 1.1. Vous pouvez donc l'utiliser sur Arch ou (k) Ubuntu 19.04+. Vous devrez peut-être utiliser le script d'installation .NET-Core , car il n'y a pas encore de packages.
A la hausse, 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 .NET Core, WinForms et WPF dans .NET-Core ne fonctionneront que sur Windows, car WinForms / WPF utilisera l'API Windows.
Remarque:
.NET Core 3.0 est désormais disponible (RTM) et il existe une prise en charge de WinForms et WPF, mais uniquement pour C # (sous Windows). Il n'y a pas de WinForms-Core-Designer . Le concepteur proposera éventuellement une mise à jour de Visual Studio. La prise en charge de WinForms pour VB.NET n'est pas prise en charge , mais est prévue pour .NET 5.0 en 2020 .
PS:
echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1
Si vous l'avez utilisé sur 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 n'incluent pas d'arguments de ligne de commande.
Les données sont collectées par Microsoft et partagées avec la communauté.
Vous pouvez désactiver la télémétrie en définissant une variable d'environnement DOTNET_CLI_TELEMETRY_OPTOUT sur 1 à l'aide de 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 .
Je pensais mentionner que je pense que le monodéveloppement (alias Xamarin Studio, Mono IDE ou Visual Studio Mac comme on l'appelle maintenant sur Mac) a évolué assez bien et est - en attendant - largement utilisable.
Cependant, JetBrains Rider (EAP 2018 à ce stade) est certainement beaucoup plus agréable et plus fiable (et le décompilateur inclus est plus sûr), c'est-à-dire si vous développez .NET-Core sur Linux ou Mac. MonoDevelop ne prend pas en charge Debug-StepThrough sous Linux dans .NET Core, car MS ne concède pas de licence à sa DLL d'API de débogage (sauf pour VisualStudio Mac ...). Cependant, vous pouvez utiliser le débogueur Samsung pour .NET Core via l' extension de débogage .NET Core pour Samsung Debugger pour MonoDevelop
Avertissement:
je n'utilise pas 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 à des processeurs ARM (ARM-64?) Auto-fabriqués, une grande partie de ce qui s'applique à Mac en ce moment pourrait ne pas s'appliquer à Mac à l'avenir (2020+).
De plus, lorsque j'écris "mono est assez instable et lent", l'instable concerne les applications WinFroms et WebForms, en particulier l'exécution d'applications Web via fastcgi ou avec XSP (sur la version 4.x de mono), ainsi que la sérialisation XML -gestion des particularités, et le relativement lent concerne WinForms, et les expressions régulières en particulier (ASP.NET-MVC utilise également des expressions régulières pour le routage).
Lorsque j'écris sur mon expérience des modes mono 2.x, 3.x et 4.x, cela ne signifie pas nécessairement que ces problèmes n'ont pas été résolus à l'heure actuelle, ni au moment où vous lisez ceci, ni que s'ils le sont corrigé maintenant, qu'il ne peut pas y avoir de régression plus tard qui réintroduit aucun de ces bogues / fonctionnalités. Cela ne signifie pas non plus que si vous intégrez le mono-runtime, vous obtiendrez les mêmes résultats que lorsque vous utiliserez le mono-runtime du système (dev). Cela ne signifie pas non plus que l'incorporation du mono-runtime (n'importe où) est nécessairement gratuite.
Tout cela ne signifie pas nécessairement que le mono est mal adapté à iOS ou Android, ou qu'il a les mêmes problèmes là-bas. 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é, la convivialité, les coûts et les performances sur ces plates-formes. De toute évidence, si vous utilisez .NET sur Android, vous devez également prendre en compte d'autres coûts, tels que la pondération des coûts xamarin par rapport aux coûts et au temps de portage du code existant vers Java. On entend du mono sur Android et IOS doit être assez bon. Prenez-le 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 par rapport à 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 des polices Windows soient présentes .