Mono est-il prêt pour les heures de grande écoute? [fermé]

Quelqu'un a-t-il utilisé Mono, l'implémentation open source .NET sur un projet de grande ou moyenne taille? Je me demande s'il est prêt pour le monde réel, les environnements de production. Est-il stable, rapide, compatible, ... assez à utiliser? Faut-il beaucoup d'efforts pour porter des projets vers le runtime Mono, ou est-ce vraiment, vraiment assez compatible pour simplement prendre et exécuter du code déjà écrit pour le runtime de Microsoft?

Il y a quelques scénarios à considérer: (a) si vous portez une application existante et vous demandez si Mono est assez bon pour cette tâche; (b) vous commencez à écrire du nouveau code et vous voulez savoir si Mono est suffisamment mature.

Dans le premier cas, vous pouvez utiliser l' outil Mono Migration Analyzer (Moma) pour évaluer la distance d'exécution de votre application sur Mono. Si l'évaluation revient avec brio, vous devriez commencer vos tests et QA et préparez-vous à expédier.

Si votre évaluation revient avec un rapport mettant en évidence les fonctionnalités manquantes ou dont la sémantique diffère considérablement dans Mono, vous devrez é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 statistiques de Moma basées sur les soumissions des utilisateurs (c'est de mémoire), environ 50% des applications fonctionnent hors de la boîte, environ 25% nécessitent environ une semaine de travail (refactoring, adaptation) et 15% nécessitent un engagement sérieux pour refaire des morceaux de votre code, et le reste ne vaut tout simplement pas la peine d'être porté car ils sont si incroyablement liés à Win32. À ce stade, soit vous partez de zéro, soit une décision commerciale entraînera l'effort de rendre votre code portable, mais nous parlons de mois de travail (au moins d'après les rapports que nous avons).

Si vous partez de zéro, la situation est beaucoup plus simple, car vous n'utiliserez que les API présentes dans Mono. Tant que vous restez avec la pile prise en charge (qui est à peu près .NET 2.0, ainsi que toutes les mises à niveau principales de la version 3.5, y compris LINQ et System.Core, ainsi que toutes les API multiplateformes Mono), tout ira bien.

De temps en temps, vous pourriez rencontrer des bogues dans Mono ou des limitations, et vous devrez peut-être les contourner, mais ce n'est pas différent de tout autre système.

En ce qui concerne la portabilité: les applications ASP.NET sont les plus faciles à porter, car celles-ci ont peu ou pas de dépendances sur Win32 et vous pouvez même utiliser SQL Server ou d'autres bases de données populaires (il existe de nombreux fournisseurs de bases de données groupés avec Mono).

Le portage de Windows.Forms est parfois plus délicat car les développeurs aiment échapper au bac à sable .NET et invoquer leur cerveau pour configurer des choses aussi utiles que la modification du taux de clignotement du curseur exprimé sous la forme de deux points bezier encodés sous forme BCD dans un wParam. Ou des ordures comme ça.

Il a une couverture assez étendue jusqu'à .NET 4.0 et inclut même certaines fonctionnalités des API .NET 4.5, mais il y a quelques domaines que nous avons choisi de ne pas implémenter en raison de la dépréciation des API, de la création de nouvelles alternatives ou de l'étendue trop grand. Les API suivantes ne sont pas disponibles dans Mono:

• Windows Presentation Foundation
• Windows Workflow Foundation (aucune des deux versions)
• Cadre d'entité
• Les "modules complémentaires" WSE1 / WSE2 à la pile de services Web standard

De plus, notre implémentation WCF est limitée à ce que Silverlight a pris en charge.

La façon la plus simple de vérifier votre projet spécifique consiste à exécuter le Mono Migration Analyzer (MoMA) . L'avantage est qu'il informera l'équipe Mono des problèmes qui vous empêcheront d'utiliser Mono (le cas échéant), ce qui lui permettra de hiérarchiser son travail.

J'ai récemment exécuté MoMA sur SubSonic et trouvé un seul problème - une utilisation étrange des types Nullable. C'est une grande base de code, donc la couverture y était assez impressionnante.

Mono est utilisé activement dans plusieurs produits commerciaux et open source . Il est utilisé dans certaines grandes applications, telles que Wikipedia et le Mozilla Developer Center , et a été utilisé dans des applications intégrées telles que les lecteurs MP3 Sansa et alimente des milliers de jeux publiés.

Au niveau du langage, le compilateur Mono est entièrement conforme à la spécification du langage C # 5.0 .

Côté bureau, Mono fonctionne très bien si vous vous engagez à utiliser GTK #. L'implémentation de Windows.Forms est encore un peu boguée (par exemple, TrayIcon ne fonctionne pas) mais elle a parcouru un long chemin. En outre, GTK # est une meilleure boîte à outils que Windows Forms.

Côté web, Mono a implémenté suffisamment d'ASP.NET pour exécuter parfaitement la plupart des sites. La difficulté ici est de trouver un hôte sur lequel mod_mono est installé sur apache, ou de le faire vous-même si vous avez un accès shell à votre hôte.

Quoi qu'il en soit, Mono est génial et stable.

Éléments clés à retenir lors de la création d'un programme multiplateforme:

• Utilisez GTK # au lieu de Windows.
• Assurez-vous de bien caser vos noms de fichiers
• Utilisez Path.Separatorau lieu du codage en dur "\", utilisez également Environment.NewLineau lieu de "\n".
• N'utilisez aucun appel P / appelé à l'API Win32.
• N'utilisez pas le registre Windows.

Personnellement, j'utilise Mono dans un environnement aux heures de grande écoute. J'exécute des serveurs mono traitant des giga-octets de tâches liées au traitement des données udp / tcp et je ne pourrais pas être plus heureux.

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

• MonoDevelop (l'IDE) a une prise en charge partielle de msbuild, mais fonctionnera essentiellement sur n'importe quelle configuration de construction "REAL" au-delà d'un simple bonjour-monde (tâches de construction personnalisées, "propriétés" dynamiques comme $ (SolutionDir), configuration réelle pour nommer quelques morts) -prend fin)
• xbuild qui DEVRAIT être le système de build mono-fourni-msbuild-entièrement-compatible est encore plus horrible, donc la construction à partir de la ligne de commande est en fait une expérience pire que l'utilisation de l'interface graphique, qui est un état très "peu orthodoxe" de la union pour les environnements Linux ...

Une fois / Pendant que vos trucs sont réellement CONSTRUITS, vous pourriez voir des déserts même pour le code qui DEVRAIT être pris en charge comme:

• le compilateur se faufilant sur certaines constructions
• et certaines classes .NET plus avancées / nouvelles vous jettent des conneries inattendues (XLinq n'importe qui?)
• quelques "fonctionnalités" d'exécution immatures (limite de 3 Go sur x64 ... WTF!)

mais Heaving a dit que, d'une manière générale, les choses commencent à fonctionner très rapidement et que les solutions / contournements sont abondants .

Une fois que vous avez franchi ces obstacles initiaux, mon expérience est que les ROCKS mono, et continue de s'améliorer à chaque itération .

J'ai eu des serveurs fonctionnant avec mono, traitant 300 Go de données par jour, avec des tonnes de p / invokes et en général faisant beaucoup de travail et restant UP pendant 5-6 mois, même avec le mono "edge".

J'espère que cela t'aides.

Les recommandations pour la réponse acceptée sont maintenant un peu dépassées.

• L'implémentation des formulaires Windows est assez bonne maintenant. (Voir Paint-Mono pour un port de Paint.net qui est une application Windows Forms assez impliquée. Tout ce qui était requis était une couche d'émulation pour certains des appels système P-Invoke et non pris en charge).
• Path.Combine ainsi que Path.Seperator pour joindre les chemins et les noms de fichiers.
• Le registre Windows est OK, tant que vous ne l'utilisez que pour stocker et récupérer des données de vos applications (c'est-à-dire que vous ne pouvez pas obtenir d'informations sur Windows, car il s'agit essentiellement d'un registre pour les applications Mono).

Si vous souhaitez utiliser WPF, vous n'avez pas de chance, Mono n'a actuellement pas l'intention de le mettre en œuvre.

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

Eh bien, le mono est génial, mais pour autant que je puisse voir, il est instable. Cela fonctionne, mais des défauts lorsque vous donnez au processus mono un travail sérieux à faire.

TL; DR - N'utilisez pas mono si vous:

• utiliser AppDomains (Assembly Load \ Unload) dans des environnements multithread
• Ne peut pas soutenir le modèle «laissez-le-échouer»
• Découvrez des événements occasionnels de forte charge pendant l'exécution du processus

Donc, les faits.

Nous utilisons mono-2.6.7 (.net v 3.5) sur RHEL5, Ubuntu et, à mon avis, c'est la version la plus stable construite par Novell. Il y a un problème avec Unloading AppDomains (segfaults), cependant, il échoue très rarement et cela, de loin, est acceptable (par nous).

D'accord. Mais si vous souhaitez utiliser les fonctionnalités de .net 4.0, vous devez passer aux 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 à utiliser. J'ai écrit une application de test de stress simple pour tester les installations mono.

Il est ici, avec des instructions d'utilisation: https://github.com/head-thrash/stress_test_mono

Il utilise des threads Worker Pool Worker. Le travailleur charge la DLL sur AppDomain et essaie de faire un travail mathématique. Une partie du travail est multithread, une partie est unique. Presque tout le travail est lié au CPU, bien qu'il y ait quelques lectures de fichiers à partir du disque.

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

• sgen GC segfaults traite presque immédiatement
• mono avec boehm vit plus longtemps (de 2 à 5 heures), mais segfaults 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]

Quant aux 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 extrait 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 en quelque sorte connectés à la logique AppDomains, vous devez donc rester à l'écart d'eux en mono.

BTW, le programme testé a fonctionné 24 heures sur la machine Windows dans MS .NET 4.5 env sans aucun échec.

Donc, en conclusion, je voudrais dire - utilisez le mono avec prudence. Il fonctionne dès le premier coup d'œil, mais peut facilement échouer à tout moment. Vous vous retrouveriez avec un tas de vidages de mémoire et une perte de foi majeure dans les projets open source.

Le MoMA est un excellent outil pour cela, comme quelqu'un l'a suggéré. Les plus grandes sources d'incompatibilité de nos jours sont les applications qui importent Dll (ou P / Invoke) dans les bibliothèques Win32. Certains assemblys ne sont pas implémentés, mais la plupart d'entre eux sont uniquement Windows et n'ont vraiment aucun sens sur Linux. Je pense qu'il est assez sûr de dire que la plupart des applications ASP.NET peuvent fonctionner sur Mono avec des modifications limitées.

(Divulgation: j'ai contribué à Mono lui-même, ainsi qu'à des applications écrites qui s'exécutent par-dessus.)

Dans de nombreux cas, vous pouvez prendre le code existant et l'exécuter simplement sur Mono, en particulier si vous portez une application ASP.NET.

Dans certains cas, vous pouvez avoir besoin de nouvelles sections de code pour le faire fonctionner. Si vous utilisez System.Windows.Forms, par exemple, l'application ne fonctionnera pas sans modification. De même si vous utilisez un code spécifique à Windows (code d'accès au registre, par exemple). Mais je pense que le pire délinquant est le code UI. C'est particulièrement mauvais sur les systèmes Macintosh.

Nous l'avons utilisé pour un projet ici au travail qui devait s'exécuter sur Linux mais réutiliser certaines bibliothèques .NET que nous avons construites en Managed C ++. J'ai été très surpris de voir à quel point cela a fonctionné. Notre exécutable principal est écrit en C # et nous pouvons simplement référencer nos binaires Managed C ++ sans problème. La seule différence dans le code C # entre Windows et Linux est le code de port série RS232.

Le seul gros problème auquel je puisse penser s'est produit il y a environ un mois. La version Linux avait une fuite de mémoire qui n'était pas vue sur la version Windows. Après avoir effectué un débogage manuel (les profileurs de base pour Mono sur Linux n'ont pas beaucoup aidé), nous avons pu réduire le problème à un morceau de code spécifique. Nous avons finalement corrigé une solution de contournement, mais j'ai encore besoin de trouver du temps pour revenir en arrière et découvrir quelle était la cause première de la fuite.

Savez-vous à quel point le support de l'aperçu Mono 2.0 est bon pour Windows Forms 2.0?

Du peu que j'ai joué avec, il semblait relativement complet et presque utilisable. Cela ne semblait pas tout à fait correct à certains endroits et est toujours un peu hasardeux dans l'ensemble. Cela m'a étonné que cela ait fonctionné aussi bien que sur certaines de nos formes, mais honnêtement.

Oui, c'est certainement le cas (si vous faites attention cependant) Nous prenons en charge Mono dans Ra-Ajax (bibliothèque Ajax trouvée sur http://ra-ajax.org ) et nous n'avons généralement pas de problèmes du tout. Vous devez être prudent avec certaines des "choses les plus folles" de .Net comme WSE, etc., et aussi probablement quelques-uns de vos projets existants ne seront pas 100% mono compatibles, mais les nouveaux projets si vous les testez pendant le développement seront être compatible sans problème avec Mono. Et le gain de la prise en charge de Linux, etc. en utilisant Mono est vraiment cool;)

Je pense qu'une grande partie du secret de la prise en charge de Mono consiste à utiliser les bons outils dès le début, par exemple ActiveRecord, log4net, ra-ajax, etc.

Pour le type d'application que nous construisons, Mono ne semble malheureusement pas prêt pour la production. Nous avons été impressionnés par l'ensemble et impressionnés par ses performances à la fois sur Windows et sur les machines EC2, cependant, notre programme s'est écrasé régulièrement avec des erreurs de récupération de place sur Windows et Linux.

Le message d'erreur est: "Erreurs fatales dans GC: trop de sections de tas", voici un lien vers quelqu'un d'autre rencontrant le problème d'une manière légèrement différente:

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

Le premier morceau de code que nous avons exécuté dans Mono était un simple défi de programmation que nous avions développé ... Le code charge environ 10 Mo de données dans certaines structures de données (par exemple, HashSets), puis exécute 10 requêtes sur les données. Nous avons exécuté les requêtes 100 fois afin de les chronométrer et d'obtenir une moyenne.

Le code s'est écrasé autour de la 55e requête sous Windows. Sous Linux, cela a fonctionné, mais dès que nous sommes passés à un ensemble de données plus important, il se bloquait également.

Ce code est très simple, par exemple, mettre des données dans des HashSets, puis interroger ces HashSets, etc., tous en C # natif, rien de dangereux, pas d'appels d'API. Sur le Microsoft CLR, il ne se bloque jamais et fonctionne sur des ensembles de données énormes des milliers de fois très bien.

Un de nos gars a envoyé un courriel à Miguel et a inclus le code qui a causé le problème, aucune réponse pour le moment. :(

Il semble également que de nombreuses autres personnes aient rencontré ce problème sans solution - une solution a été suggérée pour recompiler Mono avec différents paramètres GC, mais cela semble simplement augmenter le seuil avant lequel il se bloque.

Consultez simplement www.plasticscm.com. Tout (client, serveur, interface graphique, outils de fusion) est écrit en mono.

Cela dépend vraiment des espaces de noms et des classes que vous utilisez à partir du framework .NET. J'avais intérêt à convertir l'un de mes services Windows pour qu'il s'exécute sur mon serveur de messagerie, qui est Suse, mais nous avons rencontré plusieurs barrages routiers durs avec des API qui n'avaient pas été complètement implémentées. Il y a un tableau quelque part sur le site Web Mono qui répertorie toutes les classes et leur niveau d'achèvement. Si votre demande est couverte, allez-y.

Comme toute autre application, faites bien sûr du prototypage et des tests avant de vous engager pleinement.

Un autre problème que nous avons rencontré est le logiciel sous licence: si vous faites référence à la DLL de quelqu'un d'autre, vous ne pouvez pas vous frayer un chemin autour des incompatibilités qui sont enfouies dans cet assemblage.

J'imagine alors que si vous avez une application avec des composants tiers, vous pourriez être bourré. Je doute que beaucoup de fournisseurs se développent avec Mono en tête

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

Non, le mono n'est pas prêt pour un travail sérieux. J'ai écrit quelques programmes sur Windows en utilisant F # et les ai exécutés sur Mono. Ces programmes utilisaient le disque, la mémoire et le processeur de manière assez intensive. J'ai vu des plantages dans des bibliothèques mono (code managé), des plantages en code natif et des plantages dans la machine virtuelle. Lorsque mono fonctionnait, les programmes étaient au moins deux fois plus lents qu'en .Net sous Windows et utilisaient beaucoup plus de mémoire. Éloignez-vous du mono pour un travail sérieux.