Est Mono prêt pour le prime time?[fermé]

https://stackoverflow.com/questions/18450

09-06-2019
|

Question

Quelqu'un a utilisé Mono, l'open source .NET mise en œuvre sur une grande ou moyenne taille du projet?Je me demande si il est prêt pour le monde réel, les environnements de production.Il est stable, rapide, compatible, ...assez pour l'utiliser?Faut-il beaucoup d'efforts pour que les projets portuaires pour le Mono d'exécution, ou est-il vraiment, vraiment compatible suffit de prendre et d'exécuter déjà écrit de code pour Microsoft runtime?

La solution

Il ya un couple de scénarios à prendre en considération:(a) si vous êtes portage d'une application et vous demandez-vous si Mono est assez bon pour cette tâche;(b) vous êtes de commencer à écrire du nouveau code, et vous voulez savoir si Mono est assez mature.

Pour le premier cas, vous pouvez utiliser le Mono Migration de l'outil d'Analyseur (Moma) à évaluer dans quelle mesure votre application d'exécution sur Mono.Si l'évaluation est de retour avec brio, vous devriez commencer sur vos tests et d'assurance qualité et d'obtenir des prêts à expédier.

Si votre évaluation est de retour avec un rapport soulignant les caractéristiques qui manquent ou qui diffèrent de façon significative dans leur sémantique en Mono, vous aurez à évaluer si le code peut être adapté, réécrit ou, dans le pire des cas, si votre application peut fonctionner avec des fonctionnalités réduites.

Selon nos Moma statistiques sur la base des soumissions d'utilisateur (c'est de mémoire) environ 50% des demandes de travail hors de la boîte, environ 25% ont besoin d'environ une semaine de travail (refactoring, l'adaptation) d'un autre 15%, exige un engagement sérieux pour refaire des morceaux de votre code, et le reste est tout simplement pas se donner la peine de portage, car ils sont tellement liés à Win32.À ce stade, vous commencez à partir de zéro, ou d'une décision d'affaires vont stimuler l'effort pour rendre votre code portable, mais nous parlons des mois de travail (au moins à partir des rapports que nous avons).

Si vous partez de zéro, la situation est beaucoup plus simple, car vous serez seulement à l'aide de l'Api qui sont présents dans le Mono.Aussi longtemps que vous restez avec la pris en charge de la pile (qui est assez bien .NET 2.0, ainsi que toutes les mises à niveau en 3.5 y compris LINQ et du Système.De base, en plus de toute de la Mono croix-plate-forme Api), vous serez bien.

Chaque fois que dans un certain temps vous pourriez avoir des bugs en Mono ou limitations, et vous pourriez avoir à travailler autour d'eux, mais ce n'est pas différente de celle de tout autre système.

Comme pour la portabilité:ASP.NET les applications sont les plus faciles à port, que ceux qui ont peu ou pas de dépendances sur Win32 et vous pouvez même utiliser le serveur SQL ou d'autres bases de données populaires (il y a beaucoup de base de données fournie avec des fournisseurs Mono).

De Windows.Les formulaires de transfert est parfois plus délicat, car les développeurs comme pour échapper à l' .NET bac à sable et de P/Invoke leur cerveau pour configurer des choses aussi utile que le changement du curseur clignotant taux exprimé par deux courbes de bézier de points codés en BCD forme dans un wParam.Ou un peu de cochonneries comme ça.

Autres conseils

Il a assez vaste couverture jusqu'à .NET 4.0 et même de les inclure certaines fonctionnalités de la .NET 4.5 Api, mais il y a quelques domaines que nous avons choisi de ne pas mettre en œuvre en raison de l'Api d'être obsolète, de nouvelles alternatives en cours de création ou de la portée trop large.Les Api suivantes ne sont pas disponibles en Mono:

Windows Presentation Foundation
Windows Workflow Foundation (aucune des deux versions)
Entity Framework
Le WSE1/WSE2 "add-ons" pour les Services Web standard de la pile

En outre, notre WCF mise en œuvre est limitée à ce que Silverlight pris en charge.

La meilleure façon de vérifier pour votre projet spécifique est d'exécuter l' Mono Migration De L'Analyseur (MoMA).L'avantage est que, il devra en aviser l'équipe de Mono de questions qui vous empêchent d'utiliser Mono (le cas échéant), ce qui leur permet de donner la priorité à leur travail.

J'ai récemment rencontré le MoMA sur Subsonique et trouvé un seul problème - un drôle de l'utilisation de types Nullables.C'est une grosse base de code, de sorte que la couverture était assez impressionnant.

Mono est en cours d'utilisation dans plusieurs commerciaux ainsi que des produits open source.Il est d'usage dans certaines grandes applications, telles que Wikipédia et le Mozilla Developer Center, et a été utilisé dans des applications embarquées telles que les lecteurs MP3 Sansa et les pouvoirs des milliers de jeux.

Au niveau du langage, le Mono compilateur est entièrement compatible avec le C# 5.0 langage de spécification.

Sur le bureau à côté, Mono fonctionne très bien si vous vous engagez à utiliser GTK#.Le Windows.Les formulaires de mise en œuvre est encore un peu buggé (par exemple, TrayIcon de ne pas travailler), mais elle a parcouru un long chemin.En outre, GTK#, c'est une meilleure trousse d'outils de Windows Forms comme il est.

Sur le web côté, Mono a mis en place suffisamment de ASP.NET pour exécuter la plupart des sites parfaitement.La difficulté ici est de trouver un hôte qui a mod_mono installé sur un serveur apache ou le faire vous-même si vous avez un accès shell à votre hôte.

De toute façon, Mono est grande, et stable.

Points importants à retenir lors de la création d'une plate-forme de programme:

L'utilisation de GTK# au lieu de Windows.Les formes
Assurer correctement le cas où vos noms de fichiers
Utilisation Path.Separator au lieu de coder en dur "\", utilisez aussi Environment.NewLine au lieu de "\n".
Ne pas utiliser de P/Invoquée appels à l'API Win32.
Ne pas utiliser le Registre de Windows.

Personnellement, j'utilise Mono dans un premier temps env.- Je exécuter mono serveurs de traiter avec des giga-octets de udp/tcp de traitement des données des tâches liées et ne pouvais pas être plus heureux.

Il y a des particularités, et l'une des choses les plus irritantes, c'est que vous ne pouvez pas simplement "construire" votre msbuild des fichiers en raison de Mono état actuel:

MonoDevelop (l'IDE) a certains partielle msbuild soutien, mais, fondamentalement, bork sur une "VRAIE" construire conf au-delà d'un simple hello world (personnalisé créer des tâches, dynamique "propriétés" comme $(SolutionDir), configuration réelle pour ne citer que quelques culs-de-sac)
xbuild qui DOIT avoir été le mono-fourni-msbuild-entièrement compatible-construire le système est encore plus horrible, de sorte que la construction de la ligne de commande est en fait une pire expérience que l'aide de l'interface utilisateur, ce qui est très "orthodoxe" de l'état de l'union pour les environnements Linux...

Une fois le/Lors de l'obtention de vos trucs réellement CONSTRUITE, vous pourriez voir certains déserts, même pour le code qui DOIT être pris en charge comme:

le compilateur arriver complètement foireuse sur certaines constructions
et certains plus avancés/nouveau .NET les classes de jeter de l'onu prévu de la merde à vous (XLinq quelqu'un?)
certains immatures runtime "caractéristiques" (3GB tas de limite SUR x64...WTF!)

mais le soulèvement a déclaré que, de façon générale, les choses commencent à travailler très rapidement, et les solutions/solutions de contournement sont abondants.

Une fois que vous avez dépassé ces premiers obstacles, mon expérience est que les mono ROCHERS, et ne cesse de s'améliorer à chaque itération.

J'ai eu des serveurs exécutant avec mono, le traitement de 300 go de données par jour, avec des tonnes de p/invoque et, plus généralement, de faire BEAUCOUP de travail et de séjour pour les 5-6 mois, même avec le "bleeding edge" mono.

Espérons que cette aide.

Les recommandations pour la accepté de réponse sont un peu hors de date.

Les windows forms mise en œuvre est assez bon maintenant.(Voir Peinture-Mono pour un port de Paint.net ce qui est plutôt impliqué application Windows forms.Tout ce qui était nécessaire, c'était une couche d'émulation pour certains de la P-Invoquer et de non prise en charge des appels système).
Chemin d'accès.Combiner ainsi que le Chemin d'accès.Séparateur pour rejoindre les chemins et noms de fichiers.
Le Registre windows est OK, tant que vous êtes seul à l'utiliser pour stocker et récupérer des données à partir de vos applications (c'est à direvous ne pouvez pas obtenir toutes les informations au sujet de Windows, vu qu'il est fondamentalement un registre pour les applications Mono).

Si vous souhaitez utiliser WPF vous'rr hors de la chance Mono a actuellement pas de plans à mettre en œuvre.

http://www.mono-project.com/WPF

Eh bien, mono est grande, mais aussi loin que je peux voir, c'est instable.Il fonctionne, mais les défauts lorsque vous donnez mono processus d'un travail sérieux à faire.

TL;DR - Ne pas utiliser mono si vous :

l'utilisation de domaines d'application (Assemblée de Charger / supprimer) dans des environnements multithreads
Ne peuvent pas soutenir "let-it-échec du" modèle
L'expérience occasionnelle lourde charge les événements pendant l'exécution du processus

Donc, les faits.

Nous utilisons mono-2.6.7 (.net v 3.5) sur RHEL5, Ubuntu, et, de mon point de vue, il est plus stable version construite par Novell.Il a un problème avec le Déchargement des domaines d'application (segmentation), elle ne parvient cependant pas très rare, et ce, de loin, est acceptable (par nous).

Ok.Mais si vous souhaitez utiliser les fonctions de .net 4.0, vous devez passer à des versions 2.10.x ou 3.x, et c'est là que les problèmes commencent.

Par rapport à 2.6.7, les nouvelles versions sont tout simplement inacceptables pour être utilisé.J'ai écrit un simple test de stress de l'application de tests mono installations.

C'est ici, avec des instructions pour l'utilisation : https://github.com/head-thrash/stress_test_mono

Il utilise des Threads du Pool de Threads de travail.Travailleur charges dll pour domaine d'application et essaie de faire quelques calculs-travail.Certains des travaux est de plusieurs threads, certains est unique.Presque tout le travail est lié au PROCESSEUR, bien qu'il existe quelques lectures de fichiers à partir du disque.

Les résultats ne sont pas très bonnes.En fait, pour la version 3.0.12:

sgen GC processus de segmentation presque immédiatement
mono avec boehm vie plus longue (de 2 à 5 heures), mais les erreurs de segmentation finalement

Comme mentionné ci-dessus, sgen gc ne fonctionne tout simplement pas (mono construit à partir de la source):

* Assertion: should not be reached at sgen-scan-object.h:111

Stacktrace:


Native stacktrace:

    mono() [0x4ab0ad]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x2b61ea830cb0]
    /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x2b61eaa74425]
    /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x2b61eaa77b8b]
    mono() [0x62b49d]
    mono() [0x62b5d6]
    mono() [0x5d4f84]
    mono() [0x5cb0af]
    mono() [0x5cb2cc]
    mono() [0x5cccfd]
    mono() [0x5cd944]
    mono() [0x5d12b6]
    mono(mono_gc_collect+0x28) [0x5d16f8]
    mono(mono_domain_finalize+0x7c) [0x59fb1c]
    mono() [0x596ef0]
    mono() [0x616f13]
    mono() [0x626ee0]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x2b61ea828e9a]
    /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x2b61eab31ccd]

Comme pour boehm segfauls - par exemple (Ubuntu 13.04, mono construit à partir de la source):

mono: mini-amd64.c:492: amd64_patch: Assertion `0' failed.
Stacktrace:
at <unknown> <0xffffffff>
at System.Collections.Generic.Dictionary`2.Init (int,System.Collections.Generic.IEqualityComparer`1<TKey>) [0x00012] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:264
at System.Collections.Generic.Dictionary`2..ctor () [0x00006] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:222
at System.Security.Cryptography.CryptoConfig/CryptoHandler..ctor (System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00014] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/Crypto
Config.cs:582
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00013] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoCo
nfig.cs:473
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /home/bkmz/my/mono/mcs/class/corlib/System/Guid.cs:492

Ou (RHEL5, mono est pris à partir de rpm ici ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/vmas%3A/mono-centos5)

Assertion at mini.c:3783, condition `code' not met
Stacktrace:
at <unknown> <0xffffffff>
at System.IO.StreamReader.ReadBuffer () [0x00012] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:394
at System.IO.StreamReader.Peek () [0x00006] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:429
at Mono.Xml.SmallXmlParser.Peek () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:271
at Mono.Xml.SmallXmlParser.Parse (System.IO.TextReader,Mono.Xml.SmallXmlParser/IContentHandler) [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:346
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00021] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptog
raphy/CryptoConfig.cs:475
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/Guid.cs:483
at System.Runtime.Remoting.RemotingServices.NewUri () [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:356
at System.Runtime.Remoting.RemotingServices.Marshal (System.MarshalByRefObject,string,System.Type) [0x000ba] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:329
at System.AppDomain.GetMarshalledDomainObjRef () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/AppDomain.cs:1363

Les deux échecs sont liés à des domaines d'application de la logique, donc, vous devriez rester loin d'eux en mono.

BTW, programme testé travaillé 24 heures sur machine Windows dans la SEP .NET 4.5 env sans échec).

Donc, en conclusion, je voudrais dire - mono avec prudence.Cela fonctionne du premier coup d'œil, mais peut échouer à chaque fois.Vous seriez gauche avec un tas de core dumps et des religions les plus importantes de la perte dans les projets open source.

Le MoMA est un excellent outil pour cela, que quelqu'un d'autre a suggéré.Les sources les plus importantes de l'incompatibilité de ces jours sont des applications qui DllImport (ou P/Invoke) dans Win32 bibliothèques.Certains assemblages ne sont pas mis en œuvre, mais la plupart d'entre eux sont pour Windows uniquement et ne serait vraiment pas de bon sens sur Linux.Je pense que c'est assez sûr de dire que la plupart des ASP.NET les applications peuvent s'exécuter sur des Mono avec peu de modifications.

(Divulgation:J'ai contribué à Mono, ainsi que les écrits des applications qui s'exécutent sur le dessus de cela.)

Dans de nombreux cas, vous pouvez prendre le code et l'exécuter sur Mono, en particulier si vous êtes le portage d'une ASP.NET application.

Dans certains cas, vous pouvez avoir tout de nouvelles sections de code pour le faire fonctionner.Si vous utilisez le Système.De Windows.Formes, par exemple, l'application ne fonctionne pas non modifiée.De même, si vous utilisez Windows-code spécifique (registre de code d'accès, par exemple).Mais je pense que le pire délinquant code de l'INTERFACE utilisateur.C'est particulièrement mauvais sur les systèmes Macintosh.

Nous avons été à l'utiliser pour un projet d'ici au travail à exécuter sur Linux, mais la réutilisation de certains .NET les bibliothèques que nous avons construit dans le C++.J'ai été très surpris par la façon dont il a travaillé.Notre exécutable principal est d'être écrit en C# et nous pouvons faire référence à notre Managed C++ binaires sans problème.La seule différence dans le code C# entre Windows et Linux est un port série RS232 code.

Le seul gros problème je pense, qui est arrivé il y a un mois.Le Linux a une fuite de mémoire qui n'a pas été vu sur les Fenêtres de construire.Après avoir fait quelques manuel de débogage (base de profileurs pour Mono sous Linux n'aide pas beaucoup), nous avons été en mesure de réduire le problème vers le bas à un morceau de code.Nous nous sommes retrouvés patcher une solution de contournement, mais j'ai encore besoin de trouver un peu de temps pour revenir en arrière et comprendre quelle est la cause de la fuite a été.

Savez-vous comment bon Mono 2.0 aperçu de l'aide pour les Windows Forms 2.0?

Du peu que j'ai joué avec elle, il semblait relativement complet et presque utilisable.Il n'a tout simplement pas regarder à droite à certains endroits et est encore un peu frappé ou manquer d'ensemble.Il m'a étonné que ça fonctionne bien comme il l'a fait avec certains de nos formulaires, bien honnêtement.

Oui, il est certainement (si vous êtes prudent si) Nous soutenons Mono en Ra-Ajax (Ajax trouvé à la bibliothèque http://ra-ajax.org) et nous sommes la plupart du temps de ne pas avoir de problèmes à tous.Vous devez être prudent avec certains des plus folles choses" de .Net comme WSE etc, et aussi probablement assez quelques-uns de vos projets existants ne sera pas 100% compatible Mono, mais de nouveaux projets si vous les testez cours de développement, sera surtout compatible sans problème avec Mono.Et le gain de soutenir Linux, etc grâce à l'aide de Mono est vraiment cool ;)

Une grande partie du secret de soutien Mono je pense est d'utiliser les outils de droite dès le début, par exempleActiveRecord, log4net, ra-ajax etc...

Pour le type de demande que nous construisons en Mono, malheureusement, ne semble pas prêt pour la production.Nous avons été impressionnés par elle dans l'ensemble, et impressionné par sa performance à la fois sur Windows et sur EC2 machines, cependant, notre programme s'est écrasé consistenly avec la collecte des ordures erreurs à la fois sur Windows et linux.

Le message d'erreur est:"des erreurs fatales en GC:trop de tas de sections", voici un lien à quelqu'un d'autre rencontre le problème de manière un peu différente:

http://bugzilla.novell.com/show_bug.cgi?id=435906

Le premier morceau de code que nous avons couru dans le Mono est une programmation simple défi, nous avions développé...Le code de charges d'environ 10 mo de données dans certaines structures de données (par ex.HashSets), puis exécute 10 des requêtes sur les données.Nous avons couru les requêtes de 100 fois pour le temps et pour obtenir une moyenne.

Le code s'est écrasé autour de la 55e requête sur Windows.Sur linux, il a travaillé, mais dès que nous avons déménagé dans un plus grand ensemble de données, il crash aussi.

Ce code est très simple, par exemplemettre des données dans HashSets et ensuite d'interroger ceux HashSets etc, toutes natives en c#, rien de dangereux, pas d'appels de l'API.Sur le Microsoft CLR jamais se bloque et s'exécute sur d'énormes ensembles de données de 1000 fois l'amende juste.

Un de nos gars envoyé Miguel et le code qui a causé le problème, pas de réponse encore.:(

Il semble aussi que beaucoup d'autres personnes ont rencontré ce problème sans solution - une solution a été suggéré de recompiler Mono avec différentes GC paramètres, mais cela semble augmenter le seuil devant lequel il se bloque.

Il suffit de vérifier www.plasticscm.com.Tout (client, serveur, interface utilisateur graphique, de fusion et d'outils) est écrit sur mono.

Cela dépend vraiment sur les espaces de noms et les classes que vous utilisez à partir de la .NET framework.J'ai eu un intérêt dans la conversion de l'un de mes services windows pour s'exécuter sur mon serveur de messagerie, qui est de Suse, mais nous nous sommes heurtés à plusieurs dur barrages avec des Api qui n'a pas été entièrement mis en œuvre.Il y a un tableau quelque part sur le Mono site qui répertorie toutes les classes et leur degré de réalisation.Si votre demande est couvert, puis aller pour elle.

Comme toute autre application, faire du prototypage et de tests avant de vous faire un plein engagement, bien sûr.

Un autre problème que nous avons rencontré est logiciel sous licence:si vous faites référence à quelqu'un d'autre DLL, vous ne pouvez pas le code de votre façon de contourner les incompatibilités qui sont enterrés dans cette assemblée.

J'imagine alors si vous avez une application avec certains 3rd party composants peuvent être farcies.Je doute que beaucoup de vendeurs de développer avec Mono à l'esprit

Exemple: http://community.devexpress.com/forums/p/55085/185853.aspx

Non, mono n'est pas prêt pour un travail sérieux.J'ai écrit un certain nombre de programmes sur Windows à l'aide de F# et a couru sur Mono.Ceux-programme a utilisé le disque, la mémoire et le processeur assez intensivement.J'ai vu des accidents dans le mono (bibliothèques de code managé), les accidents de en code natif et se bloque dans la machine virtuelle.Lorsque mono travaillé les programmes ont été au moins deux fois plus lent que dans .Net dans Windows et utilisé beaucoup plus de mémoire.Rester à l'écart de mono pour un travail sérieux.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow