Mono est-il prêt pour le prime time ?

Question

Quelqu'un a-t-il utilisé Mono, l'implémentation .NET open source, dans le cadre d'un projet de taille moyenne ou importante ? Je me demande si elle est prête pour le monde réel, les environnements de production. Est-il stable, rapide, compatible, ... suffisant pour être utilisé ? Le portage de projets vers le runtime Mono demande-t-il beaucoup d'efforts, ou est-il vraiment... ? vraiment suffisamment compatible pour prendre et exécuter du code déjà écrit pour le runtime de Microsoft ?

Answer 1

Il y a plusieurs scénarios à envisager : (a) vous êtes en train de porter une application existante et vous 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 assez mature.

Dans le premier cas, vous pouvez utiliser le Outil d'analyse de la migration Mono (Moma) pour évaluer dans quelle mesure votre application est loin de fonctionner sur Mono. Si l'évaluation est positive, vous pouvez commencer les tests et l'assurance qualité et vous préparer à envoyer votre application.

Si votre évaluation donne lieu à un rapport mettant en évidence des fonctionnalités manquantes ou dont la sémantique diffère sensiblement 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 les statistiques de Moma basées sur les soumissions des utilisateurs (de mémoire), environ 50 % des applications fonctionnent immédiatement, environ 25 % nécessitent une semaine de travail (refactoring, adaptation), 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 il est si incroyablement lié à Win32. À ce stade, soit vous repartez de zéro, soit une décision d'entreprise vous incitera à faire l'effort de rendre votre code portable, mais nous parlons de mois de travail (du 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 dans la pile supportée (c'est-à-dire à peu près .NET 2.0, plus toutes les mises à niveau du noyau dans la version 3.5, y compris LINQ et System.Core, plus toutes les API multiplateformes de Mono), tout ira bien.

De temps en temps, vous pouvez 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.

Quant à la portabilité : Les applications ASP.NET sont les plus faciles à porter, car elles ont peu ou pas de dépendances avec Win32 et vous pouvez même utiliser le serveur SQL ou d'autres bases de données populaires (il y a beaucoup de fournisseurs de bases de données intégrés à Mono).

Le portage de Windows.Forms est parfois plus délicat parce que les développeurs aiment s'échapper de la sandbox .NET et faire des P/Invoke pour configurer des choses aussi utiles que la modification de la vitesse de clignotement du curseur exprimée sous la forme de deux points de bézier encodés en BCD dans un wParam. Ou quelque chose comme ça.

Answer 2

Il a une couverture assez étendue jusqu'à .N

• Fondation Windows Presentation
• Windows Workflow Foundation (aucune des deux versions)
• Entity Framework
• Les "compléments" WSE1/WSE2 à la pile de services Web standard

De plus, notre implémentation WCF est limitée à ce que Silverlight supportait.

La façon la plus simple de vérifier pour votre projet spécifique est d'exécuter la commande Analyseur de migration Mono (MoMA) . L'avantage est qu'il informera l'équipe Mono des problèmes qui vous empêcheront d'utiliser Mono (s'il y en a), ce qui leur permettra de donner la priorité à leur travail.

J'ai récemment lancé MoMA sur SubSonic et je n'ai trouvé qu'un seul problème - une utilisation bizarre des types Nullable. C'est une grosse base de code, donc la couverture est assez impressionnante.

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

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

Answer 3

Du côté des ordinateurs de 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, les TrayIcon's ne fonctionnent pas) mais elle a fait beaucoup de progrès. De plus, GTK# est une meilleure boîte à outils que Windows Forms tel qu'il est.

En ce qui concerne le Web, Mono a implémenté suffisamment d'ASP.NET pour faire fonctionner parfaitement la plupart des sites. La difficulté ici est de trouver un hôte qui a installé mod_mono 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 excellent et stable.

Points essentiels à retenir lors de la création d'un programme multiplateforme :

• Utiliser GTK# au lieu de Windows.Forms
• Veillez à respecter la casse de vos noms de fichiers
• Utilice Path.Separator au lieu de coder en dur "\" utilisent également Environment.NewLine au lieu de "\n" .
• N'utilisez pas d'appels P/Invoked à l'API Win32.
• N'utilisez pas le registre de Windows.

Answer 4

Personnellement, j'utilise le Mono dans un environnement de prime time. Je fais tourner des serveurs Mono qui traitent 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 un support partiel de msbuild, mais il se bloque sur n'importe quel "VRAI" build conf au-delà d'un simple hello-world (tâches de build personnalisées, "propriétés" dynamiques comme $(SolutionDir), configuration réelle pour ne citer que quelques impasses).
• xbuild qui Aurait dû être le système mono-supplémentaire de construction entièrement compatible est encore plus horrible, de sorte que 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 de l'union très "peu orthodoxe" pour les environnements Linux...

Une fois/pendant la construction de votre matériel, vous verrez peut-être des zones sauvages, même pour des codes qui devraient être supportés, par exemple :

• le compilateur se bloque sur certaines constructions
• et certaines classes .NET plus avancées/nouvelles qui vous envoient des conneries inattendues (XLinq, par exemple).
• certaines "fonctionnalités" immatures du moteur d'exécution (limite du tas de 3 Go sur x64... WTF !)

mais il a dit qu'en général, les choses commencent à fonctionner très rapidement, et les solutions/contournements sont abondants. .

Une fois que vous avez franchi ces obstacles initiaux, mon expérience m'a montré que le mono ROCKS et s'améliore à 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 "bleeding edge".

J'espère que cela vous aidera.

Answer 5

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

• L'implémentation des formulaires Windows est assez bonne maintenant. (Voir Peinture-Mono pour un portage de Paint.net qui est une application Windows assez complexe. Tout ce qui était nécessaire était une couche d'émulation pour certains des appels système P-Invoke et non supportés).
• Path.Combine ainsi que Path.Seperator pour joindre les chemins et les noms de fichiers.
• Le registre Windows est acceptable, à condition que vous l'utilisiez uniquement pour stocker et récupérer les données de vos applications (c'est-à-dire que vous ne pouvez pas en tirer des informations sur Windows, puisqu'il s'agit essentiellement d'un registre pour les applications Mono).