Noyau. net vs Mono

Nécromancie.

Fournir une réponse réelle.

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

.NET Core est pour la plupart une réécriture du ASP.NET MVC framework (and console applications) afin de réduire les dépendances, le rendre plus modulaire, et d'augmenter les performances.

<edit>Console Applications: this includes server applications IMHO</edit>

le point principal est d'activer"native compilation" /self-contained-deployment (vous n'avez donc pas besoin de .net framework/VM installé sur la machine cible.

Ceci est utile dans le "cloud-computing", depuis lors Vous pouvez utiliser n'importe quelle version du framework dotnet-CORE que vous aimez, et vous n'avez pas à vous soucier de quelle(S) version (s) du framework .net le sysadmin a réellement installé.

.net Core également prend en charge plusieurs systèmes d'exploitation comme un sideshow.

Il est supporté par Microsoft.

Dotnet Core ne vient pas avec Winforms ou WPF ou quelque chose comme ça.

Mono est une implémentation du .net Framework pour Linux (y compris les formulaires Web, Winforms, MVC). Essentiellement l'équivalent de (OpenJDK) JVM et (OpenJDK) JDK/JRE (par opposition à SUN/Oracle JDK). Tu peux l'utiliser pour avoir L'ASP.NET-WebForms + WinForms + ASP.NET-MVC applications pour travailler sur Linux.

Il est supporté par Xamarin, et non par Microsoft.

(puisque Xamarin a été acheté par Microsoft, c'est techniquement, mais pas vraiment, Microsoft.)

Vous obtiendrez généralement votre c # stuff à compiler sur mono, mais pas le VB.NET des trucs.

Certaines fonctionnalités avancées, comme WSE/WCF et WebParts sont manquantes.

Bon nombre des implémentations sont incomplets (par exemple, jettent NotImplementedException dans le cryptage ECDSA), buggy (par exemple ODBC/ADO.NET avec Firebird), se comportent différemment de on .NET (par exemple XML-serialization) ou autrement unstable (ASP.NET MVC) et d'une lenteur inacceptable (Regex).

cependant, ne vous attendez pas à ce que cross-plate-forme signifie que vous pourriez en fait juste apt-get install.net Core sur ARM-Linux, comme vous le pouvez avec elasticsearch. Vous devrez compiler l'ensemble du framwork à partir de source.

C'est-à-dire si vous avez cet espace (par exemple sur un Chromebook, qui a un total HD de 16 à 32 Go).

Donc, beaucoup de croix-plateforme.

j'ai trouvé une déclaration sur le site officiel qui dit, " Code écrit pour il est également portable à travers empilements d'application, tels que Mono".

aussi longtemps que ce code ne dépend pas de WinAPI-calls, Windows-dll-pinvokes, COM-Components, a système de fichiers insensible à la casse et n'a pas de problèmes de séparateur de répertoires, c'est exact. Cependant, .NET Core code 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, Je ne le recommande pas de toute façon. Essayez le traitement d'image sur .net core, par exemple WebP ou GIF mobile ou multipage-tiff ou l'écriture de texte sur une image, vous serez nastily surpris.

<edit> à la mi-février 2017: vous pouvez utiliser SkiaSharp pour celui maintenant (exemple) </edit>

Note:

À partir de .NET Core 2.0, Il y a système.Dessin.Commune (nuget), qui contient la plupart des fonctionnalités du Système.Dessin. Il devrait être plus ou moins Fonction-complète dans .NET-Core 2.1. Cependant, Système.Dessin.Utilisations communes GDI+, et ne fonctionnera donc pas sur Azure (Système.Les bibliothèques de dessin sont disponibles dans le Service Cloud Azure [fondamentalement juste un VM], mais pas dans Azure Web App [fondamentalement partagé l'hébergement?])

Jusqu'à présent, le Système.Dessin.Travaux communs très bien sur Linux / Mac.

non écrit pour .NET (non-core) n'est pas portable pour .NET core.

Ce qui signifie que si vous voulez une bibliothèque Non-GPL C comme PDFSharp pour créer des documents PDF (très courant), vous n'avez pas de chance (pour le moment) ( pas plus ). Peu importe ReportViewer control, qui utilise Windows-pInvokes (pour n'importe quelle raison), et ne fonctionne même pas sur mono sur Linux

( je travaille sur ce ).

aussi, le code écrit dans .NET core n'est pas portable En mono, parce que mono n'a pas les bibliothèques d'exécution .net core (encore).

mon but est d'utiliser C#, LINQ, EF7, visual studio pour créer un site web qui peut être exécuté/hébergé en Linux.

EF dans toutes les versions que j'ai essayées jusqu'à présent était tellement lent (même sur des choses aussi simples comme une table avec un gaucher-join), Je ne le recommanderais jamais - pas sur Windows non plus.

Je ne recommande pas particulièrement EF si vous avez une base de données avec des colonnes unique-constricins, ou varbinary/filestream/hierarchyid. (pas pour le schéma-mise à jour non plus)

Et aussi pas dans une situation où DB-performance est critique (disons 10+ à 100+ utilisateurs concurrents).

En outre, l'exécution d'un site Web/Web-application sur Linux signifiera tôt ou tard que vous devrez le déboguer.

il n'y a pas de prise en charge de débogage pour .net Core sous Linux. (non plus, mais nécessite JetBrains Rider)

MonoDevelop ne prend pas (encore) en charge les projets de débogage .NET-Core.

Si tu as des problèmes, tu es tout seul. Vous aurez à l'utilisation étendue de l'exploitation forestière.

Soyez prudent, sachez que la journalisation extensive remplira votre disque en peu de temps, surtout si votre programme entre dans une boucle infine ou une récursion.

C'est particulièrement dangereux si votre application web tourne en tant que root, parce que l'ouverture de session nécessite logfile-space-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], ainsi, au moins l'administrateur peut encore se connecter si le disque est presque plein. Mais si vos applications tournent en tant que root, cette restriction ne s'applique pas à leur utilisation de disque, et donc leurs logfiles peuvent utiliser 100% de l'espace libre restant, donc même l'administrateur ne peut plus se connecter.)

Il est donc préférable de ne pas crypter ce disque, c'est-à-dire si vous valorisez vos données/système.

Quelqu'un m'a dit qu'il voulait être "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 juste utiliser C# sur Linux/Mac. À mon avis, Il veut juste utiliser C# pour une application Web sur Linux. .NET Core est la solution pour cela, si vous voulez absolument le faire en C#. Ne pas aller avec "Mono propre"; à la surface, il semblerait que cela fonctionne d'abord - mais croyez-moi, vous le regretteriez parce que le mono est ASP.NET MVC n'est pas stable lorsque votre serveur tourne à long terme (plus de 1 jour) - vous avez été averti. Voir aussi les références" n'a pas complété " lors de la mesure de la performance mono sur les benchmarks techemepower.

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

ça veut dire qu'il veut pour utiliser un serveur web complet de haute performance comme Nginx (Engine-X), peut-être Apache.

Ensuite, il peut exécuter mono / dotnetCore avec un hébergement virtuel basé sur le nom (plusieurs noms de domaine sur la même IP) et/ou l'é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 tourne sur un fastcgi-server, et nginx transmet toutes les requêtes web pour un certain domaine via le protocole fastcgi-à celui serveur. Cela signifie également que votre site Web fonctionne 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 brouillés à destination.

Voir aussi ici et ici .

pour conclure:

.net Core n'est pas vraiment portable à l'heure actuelle, pas plus que ne l'est vraiment multiplateformes (en particulier les outils de débogage).

La compilation native n'est pas non plus facile, surtout pour ARM.

Et pour moi, il ne ressemble pas à son développement est "vraiment fini", encore.

par exemple, Système.Données.DataTable / DataAdaper.Mise à jour est manquant... (plus avec .net Core 2.0)

avec le système.Données.Commun.Bid * interfaces. (plus avec .net Core 1.1)

S'il y avait une classe qui est souvent utilisée, DataTable/DataAdapter serait elle...

Aussi, L'installateur Linux (.DEB) échoue, au moins sur ma machine, et je suis sûr que je ne suis pas le seul à avoir ce problème.

Debug, 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-post si vous faites cela - il y a un howto dans le wiki de VS-Code sur github), parce qu'ils n'offrent pas l'exécutable.

Yeoman échoue aussi. (Je suppose que cela a quelque chose à voir avec la version nodejs que vous avez installé - le code VS nécessite une version, Yeoman une autre... mais il devrait fonctionner sur le même ordinateur. assez boiteux

Peu importe qu'il tourne sur la version de noeud envoyée par défaut sur le système D'exploitation.

Jamais l'esprit qu'il ne devrait pas être dépendance sur NodeJS en premier lieu.

Le serveur kestell est également en cours de développement.

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 FastCGI-support signifie pour leur cadre, et encore moins qu'ils l'aient 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 for .NET Core "RTM"...

ainsi, lorsque vous allez exécuter .NET Core" RTM "derrière nginx, vous ne pouvez le faire qu'en procurant des requêtes à kestrell (ce serveur web semi-fini dérivé de nodeJS)-il n'y a pas de support fastcgi à l'heure actuelle dans .NET Core" RTM", AFAIK. Comme il n'y a pas de bibliothèque fastcgi core.net, ni d'échantillons, 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 questionne aussi le performance.

Dans le (préliminaire) techempower-benchmark (round 13) , aspnetcore-linux se classe sur 25% par rapport à la meilleure performance, tandis que les cadres comparables comme Go (golang) se classent à 96,9% de la performance de pointe (et c'est lorsque le retour en clair sans accès au système de fichiers seulement). .NET Core fait un peu mieux sur JSON-serialization, mais il ne semble pas convaincant non plus (go atteint 98,5% de pic, .net core 65%). Cela dit, il ne peut pas éventuellement être pire que "mono approprié".

aussi, puisqu'il est encore relativement nouveau, toutes les grandes bibliothèques n'ont pas été portées (encore), et je doute que certaines d'entre elles soient jamais portées.

Le soutien de l'imagerie est également discutable au mieux.

Pour tout cryptage, utilisez plutôt le BouncyCastle.

pouvez-vous m'aider à donner un sens à tous ces termes et si mes attentes être réaliste ?

j'espère que je vous ai aidé à faire plus de sens avec tous ces termes.

En ce qui concerne vos attentes:

Développer une application Linux sans savoir quoi que ce soit sur Linux est une idée vraiment stupide en premier lieu, et il est également lié à l'échec d'une manière ou d'une autre horrible. Cela dit, Parce que Linux vient sans frais de licence, c'est une bonne idée en principe, mais SEULEMENT SI TU SAIS CE QUE TU FAIS.

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 savoir quelles en sont les conséquences est une autre 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 soutien de débogage est un suicide, si votre projet est plus que juste 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 pour vous - puis vous obtenez de savoir ce que le cadre et ce que les problèmes non-cadre sont.

vous pouvez par exemple monter en boucle une fat32, hfs ou JFS pour votre application, pour contourner les problèmes de sensibilité à la cas (montage en boucle non recommandé dans la production).

pour résumer

À l'heure actuelle, je resterais à L'écart de .net Core (pour l'utilisation en production). Peut-être que dans un ou deux ans, tu pourras regarder à nouveau, mais probablement pas avant.

Si vous avez un nouveau projet web que vous développez, démarrez-le dans .NET Core, pas en mono.



Si vous voulez un framework qui fonctionne sur Linux (x86/AMD64/ARMhf) et Windows et Mac, qui n'a pas de dépendances, c'est-à-dire seulement des liens statiques et aucune dépendance à .NET, Java ou Windows, utilisez Golang à la place. Il est plus mature, et ses performances sont prouvées (Baidu l'utilise avec 1 million d'utilisateurs concurrents), et golang a une empreinte mémoire nettement plus faible. Aussi golang est dans les dépôts, le .DEB installe sans problèmes, le code source compile - sans exiger de modifications - et golang (entre-temps) a un support de débogage avec delve et JetBrains Gogland 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 plus.

en ce qui concerne le mono, restez à l'écart.

Il n'est rien moins étonnant de voir à quel point mono est arrivé, mais malheureusement ce n'est pas un substitut à ses problèmes de performance/évolutivité et de stabilité pour les applications de production.

En outre, mono-développement est tout à fait mort, ils en grande partie seulement développer les pièces pertinentes à Android et iOS plus, parce que C'est là où Xamarin fait leur argent.

Ne vous attendez pas à ce que le développement Web soit un Xamarin/mono-citoyen de première classe.

.NET Core pourrait en valoir la peine, si vous commencez un nouveau projet, mais pour les grands projets existants de formulaires web, le portage est largement hors de question, les changements requis sont énormes. Si vous avez un MVC-projet, la quantité de changements pourrait être gérable, si votre la conception des applications était saine, ce qui n'est généralement pas le cas pour la plupart des applications existantes dites "développées historiquement".

Décembre 2016 Mise À Jour:

La compilation Native a été retirée de la prévisualisation .net Core, car elle n'est pas encore prête...



On dirait qu'ils se sont améliorés assez fortement sur le benchmark texte-fichier brut, mais d'un autre côté, il est devenu assez buggy. Aussi, il les indices de référence JSON se sont encore détériorés. Curieux aussi que le cadre d'entité doit être plus rapide pour les mises à jour que Dapper - bien que les deux à la lenteur d'enregistrement. Ce qui est très rare pour être vrai. On dirait qu'il y a encore plus que quelques bugs à chasser.



En outre, il semble y avoir un soulagement à venir sur le front de L'IDE Linux.

IntelliJ a publié "Project Rider", une première prévisualisation D'un IDE C#/.NET Core Pour Linux (et Mac et Windows), qui peut gérer les fichiers de projet Visual Studio. Enfin un C# IDE qui est utilisable et qui n'est pas lent comme l'enfer.

Conclusion: .NET Core est toujours un logiciel de qualité pré-publication en mars 2017. Portez vos bibliothèques, mais restez à l'écart pour l'utilisation de la production, jusqu'à ce que la qualité du cadre se stabilise.

Et gardez un oeil sur Project Rider.

2017 mise à Jour

J'ai migré ma page d'accueil (de mon frère) vers le noyau.Net pour l'instant.

Jusqu'à présent, la durée D'exécution sur Linux semble être assez stable (au moins pour les petits projets) - il a survécu à un essai de charge avec facilité - mono n'a jamais fait.

En outre, 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 construire/publier sont un peu instables, mais - si vous rencontrez "nombre positif nécessaire. - Construire ÉCHOUÉ."- exécutez la même commande à nouveau, et cela fonctionne).

Vous pouvez exécuter

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

et vous obtenez un autonome .exe-file (dans le répertoire de publication), que vous pouvez déplacer vers une machine Windows 8.1 sans framework.net installé et le laisser tourner. Beau. C'est ici que dotNET-Core commence à devenir intéressant. (mind the gaps, SkiaSharp ne fonctionne pas sur Windows 8.1 / Windows Server 2012 R2, [encore] - l'écosystème doit rattraper d'abord - mais il est intéressant, le Skia-dll-load-fail ne plante pas le serveur entier/application - donc tout le reste fonctionne) "1519150920

export DOTNET_CLI_TELEMETRY_OPTOUT=1