Mono est souvent utilisé pour dire «Oui, .NET est multi-plateforme». Quelle est la validité de cette revendication? [fermé]

Dans Que choisiriez-vous pour votre projet entre .NET et Java à ce stade? Je dis que je considérerais le "Voulez-vous toujours déployer sous Windows?" la décision technique la plus importante à prendre dans un nouveau projet Web, et si la réponse est "non", je recommanderais Java au lieu de .NET.

Un contre-argument très courant est que "Si nous voulons un jour utiliser Linux / OS X / Wow, nous allons simplement utiliser Mono" ¹ , ce qui est un argument très convaincant à première vue, mais je ne suis pas d'accord avec cela à plusieurs reprises. les raisons.

• OpenJDK et tous les JVM fournis par le fournisseur ont réussi le Sun TCK officiel pour s'assurer que tout fonctionne correctement. Je ne suis pas au courant que Mono passe un Microsoft TCK.
• Mono suit les versions .NET. Quel niveau .NET est actuellement entièrement pris en charge?
• Est-ce que tous les éléments de l'interface graphique (WinForms?) Fonctionnent correctement dans Mono?
• Les entreprises peuvent ne pas vouloir dépendre des frameworks Open Source comme plan officiel B.

Je suis conscient qu'avec la nouvelle gouvernance de Java par Oracle, l'avenir est incertain, mais IBM fournit par exemple des JDK pour de nombreuses plates - formes , y compris Linux. Ils ne sont tout simplement pas open source.

Dans quelles circonstances, Mono est-il une stratégie commerciale valide pour les applications .NET?

¹ _{Mark H le résumait ainsi : "Si l'affirmation est que " j'ai une application Windows écrite en .NET, elle devrait s'exécuter en mono " , alors non, ce n'est pas une affirmation valable - mais Mono a fait des efforts pour effectuer le portage de telles applications. plus simple. "}

La réponse de Sparkie comprit , laissez-moi compléter un peu.

".NET est multi-plateforme" est une déclaration trop ambiguë, car le cadre et le monde pour lesquels il avait été créé ont changé et évolué.

La réponse courte est:

Le moteur sous-jacent qui alimente .NET et ses dérivés, le Common Language Infrastructure Standard, est multi-plateforme et, si vous souhaitez que votre code soit utilisé sur plusieurs plates-formes, vous devez planifier l'utilisation des API appropriées sur la plate-forme appropriée pour fournir la meilleure expérience sur chaque plate-forme.

La famille CLI n’a pas essayé l’approche «Une seule fois, n’importe où», car les différences entre un téléphone et un ordinateur central sont trop grandes. Au lieu de cela, un univers d’API et de fonctionnalités d’exécution spécifiques à chaque plate-forme est apparu pour donner aux développeurs les outils nécessaires pour créer de belles expériences sur chaque plate-forme.

Pensez-y: les programmeurs ne ciblent plus les PC Windows ni les serveurs Unix. Le monde, plus que jamais, est entouré de plates-formes fascinantes allant des PC aux consoles de jeux en passant par les téléphones puissants, les décodeurs, les gros serveurs et les grappes distribuées de machines. Une taille unique sur toutes les plates-formes ne ferait que se gonfler sur de petits appareils et se sentir moins puissante sur de grands systèmes .

Le produit .NET Framework de Microsoft n'est pas multiplateforme, il ne fonctionne que sous Windows. Il existe des variantes du .NET Framework de Microsoft qui s'exécutent sur d'autres systèmes, tels que Windows Phone 7, le XBox360 et les navigateurs via Silverlight, mais il s'agit tous de profils légèrement différents.

Aujourd'hui, vous pouvez cibler tous les principaux systèmes d'exploitation, téléphones, appareils mobiles, systèmes intégrés et serveurs avec les technologies .NET. Voici une liste qui indique quelle implémentation de la CLI vous utiliseriez dans chaque cas (cette liste n’est pas exhaustive, mais devrait couvrir 99% des cas):

• Ordinateurs PC basés sur x86 et x86-64:
  • sous Windows -> Généralement, vous utilisez .NET ou Silverlight, mais vous pouvez également utiliser le mode Mono complet ici.
  • sous Linux, BSD ou Solaris -> Vous utilisez Full Mono ou Silverlight
  • sous MacOS X -> Vous utilisez Full Mono ou Silverlight
  • sous Android -> Vous utilisez un sous-ensemble Mono / Android
• Ordinateurs ARM:
  • Exécution de Windows Phone 7: vous exécutez Compact Framework 2010
  • Exécution de Windows 6.5 et versions antérieures: vous exécutez l’ancien Compact Framework
  • Appareils Android: vous utilisez Mono / Android
• Ordinateurs PowerPC:
  • Vous utilisez Full Mono pour les systèmes d'exploitation Linux, BSD ou Unix complets
  • Vous utilisez Mono intégré pour PS3, Wii ou d'autres systèmes intégrés.
  • Sur XBox360, vous exécutez CompactFramework
• Ordinateurs S390, S390x, Itanium, SPARC:
  • Vous courez plein Mono
• Autres systèmes d'exploitation embarqués:
  • Vous exécutez .NET MicroFramework ou Mono avec le profil mobile.

En fonction de vos besoins, ce qui précède peut suffire ou non. Vous aurez à peine le même code source à exécuter partout. Par exemple, le code XNA ne fonctionnera pas sur tous les ordinateurs de bureau, alors que le logiciel .NET Desktop ne fonctionnera pas sur XNA ou sur le téléphone. Vous devez généralement modifier votre code pour pouvoir l'exécuter dans d'autres profils du .NET Framework. Voici quelques-uns des profils que je connais:

• Profil .NET 4.0
• Profil Silverlight
• Profil Windows Phone 7
• Profil XBox360
• Mono core Profile - suit le profil .NET et est disponible sous Linux, MacOS X, Solaris, Windows et BSD.
• .NET Micro Framework
• Mono sur iPhone
• Mono sur le profil Android
• Mono sur PS3 Profile
• Mono sur le profil Wii
• Profil Moonlight (compatible avec Silverlight)
• Profil étendu Moonlight (Silverlight + accès complet à l'API .NET 4)

Chacun de ces profils est donc légèrement différent et ce n’est pas une mauvaise chose. Chaque profil est conçu pour s'adapter à sa plate-forme hôte et exposer les API qui ont du sens, ainsi que celles qui ne le sont pas.

Par exemple, les API de Silverlight pour contrôler le navigateur de l'hôte n'ont pas de sens sur le téléphone. Et les shaders sous XNA n’ont aucun sens sur un matériel PC dépourvu du support équivalent.

Plus tôt vous vous rendrez compte que .NET n'est pas une solution pour isoler le développeur des capacités sous-jacentes du matériel et de la plate-forme native, mieux vous serez.

Cela dit, certaines API et piles sont disponibles sur plusieurs plates-formes. Par exemple, ASP.NET peut être utilisé sous Windows, sous Linux, sous Solaris et sous MacOS X car ces API existent à la fois sous .NET et Mono. ASP.NET n'est pas disponible sur certaines des plates-formes prises en charge par Microsoft, telles que XBox ou Windows Phone 7, ni sur les autres plates-formes prises en charge par Mono, telles que la Wii ou l'iPhone.

Les informations suivantes ne sont correctes qu'à compter du 21 novembre et de nombreux éléments du monde Mono vont probablement changer.

Les mêmes principes peuvent être appliqués à d'autres piles, une liste complète nécessiterait un tableau approprié, que je ne sais pas comment présenter ici, mais voici une liste de technologies qui pourraient ne pas être présentes sur une plate-forme particulière. Vous pouvez supposer que tout ce qui n'est pas répertorié ici est disponible (n'hésitez pas à m'envoyer les modifications apportées aux éléments que j'ai manqués):

Core Runtime Engine [partout]

• Prise en charge de Reflection.Emit [partout, sauf WP7, CF, Xbox, MonoTouch, PS3]
• Prise en charge du processeur SIMD [Linux, BSD, Solaris, MacOS X; Bientôt PS3, MonoTouch et MonoDroid]
• Continuations - Mono.Tasklets [Linux, BSD, Solaris, MacOS, PS3, Wii]
• Assemblage Déchargement [Windows uniquement]
• Injection de machine virtuelle [Linux, BSD, MacOS X, Solaris]
• DLR [Windows, Linux, MacOS X, Solaris, MonoDroid]
• Génériques [quelques limitations sur la PS3 et l'iPhone].

Les langues

• C # 4 [partout]
• Compilateur C # en tant que service (Linux, MacOS, Solaris, BSD, Android)
• IronRuby [partout, sauf WP7, CF, Xbox, MonoTouch, PS3]
• IronPython [partout, sauf WP7, CF, Xbox, MonoTouch, PS3]
• F # [partout, sauf WP7, CF, Xbox, MonoTouch, PS3]

Piles de serveurs

• ASP.NET [Windows, Linux, MacOS, BSD, Solaris]
• ADO.NET [partout]
• LINQ to SQL [partout]
• Entity Framework [partout]
• Pile XML principale [partout]
  • Sérialisation XML [partout, sauf WP7, CF, Xbox)
• LINQ to XML (partout)
• System.Json [Silverlight, Linux, MacOS, MonoTouch, MonoDroid]
• System.Messaging [Windows; RabbitMQ sous Linux, MacOS et Solaris]
• .NET 1 Enterprise Services [Windows uniquement]
• WCF [complet sous Windows; petit sous-ensemble sur Silverlight, Solaris, MacOS, Linux, MonoTouch, MonoDroid]
• Flux de travail Windows [Windows uniquement]
• Identité de l'espace de jeu

Piles d'interface graphique

• Silverlight (Windows, Mac, Linux - avec Moonlight)
• WPF (Windows uniquement)
• Gtk # (Windows, Mac, Linux, BSD)
• Windows.Forms (Windows, Mac, Linux, BSD)
• MonoMac - Intégration Mac native (Mac uniquement)
• MonoTouch - Intégration iPhone native (iPhone / iPad uniquement)
• MonoDroid - Intégration Android native (Android uniquement)
• API Media Center - Windows uniquement
• Clutter (Windows et Linux)

Bibliothèques graphiques

• GDI + (Windows, Linux, BSD, MacOS)
• Quartz (MacOS X, iPhone, iPad)
• Cairo (Windows, Linux, BSD, MacOS, iPhone, iPad, MacOS X, PS3, Wii)

Mono Libraries - Cross Platform, peut être utilisé en .NET mais nécessite une construction manuelle

• Compilateur C # 4 en tant que service
• Cecil - CIL Manipulation, workflow, instrumentation de CIL, Linkers
• Librairies RelaxNG
• Mono.Data. * Fournisseurs de bases de données
• Full System.Xaml (à utiliser dans les configurations où .NET ne propose pas la pile)

MonoTouch signifie Mono fonctionnant sur iPhone; MonoDroid signifie Mono fonctionnant sur Android; Les ports PS3 et Wii sont uniquement disponibles pour les développeurs qualifiés Sony et Nintendo.

Je m'excuse pour le manque de formalité.

Tout d'abord, vous devez faire la distinction entre l'infrastructure de langage commun (norme ouverte) et .NET (implémentation de Microsoft de cette norme). Mono est une implémentation de la CLI et n'a jamais prétendu être un "portable .NET". De plus, le langage C # est un standard ouvert et n'est pas strictement lié à .NET.

Je ne sais pas si Microsoft dispose d'un outil pour valider la conformité d'une implémentation, mais si c'est le cas, je suis à peu près sûr que les utilisateurs mono l'ont et l'utilisent.

Mono traîne derrière le Net, mais à peine. Mono peut exécuter du code C # 4.0 (version actuelle .NET). En outre, Microsoft a récemment rendu tous les codes et bibliothèques DLR ouverts (sous la licence Apache 2.0), ce qui a permis à mono d’utiliser des langages tels que IronPython, IronRuby et F # n’est devenu open source que la semaine dernière. En outre, Microsoft publie régulièrement des CTP des fonctionnalités à venir dans .NET, ce qui permet aux développeurs mono-utilisateurs de se tenir au courant des versions actuelles.

Il existe un certain nombre d'outils et d'extensions dans .NET, par exemple, les contrats de code. Celles-ci ne sont pas toujours implémentées entièrement en mono. (À l'heure actuelle, je pense qu'il existe un validateur de contrat partiel pour les contrats Requis). De toute façon, ceux-ci ne sont pas couramment utilisés dans les applications .NET, mais si leur popularité augmentait, leur taux d'implémentation en mono augmenterait également.

WinForms ne sont pas (entièrement) portables. Ils sont spécifiques à .NET et ne font pas partie de la CLI. La CLI ne spécifie aucun ensemble de widgets particulier. Il existe cependant des ensembles de widgets multi-plateformes (GTK # et Silverlight). Si vous étiez en train de rédiger une application en gardant à l'esprit la portabilité, vous utiliseriez l'une de ces applications plutôt que Winforms / WPF. En outre, mono fournit un wrapper fin pour l’API Winforms, ce qui permet de transférer plus facilement les applications Winforms existantes dans GTK # (sans réécriture complète).

Mono fournit un outil, l’analyseur de migration mono (MoMA), qui peut utiliser une application .Net existante et vous informer de sa portabilité. (par exemple, identifier les bibliothèques non exportables utilisées, P / Invokes, etc.).

Pour les entreprises qui ne veulent pas dépendre de l'open source, la licence mono peut faire l'objet d'une nouvelle licence. La propriété du code ajouté à mono est transférée à novell, qui peut le concéder sous une autre forme que la licence habituelle de la licence LGPL (qui présente de toute façon très peu de restrictions).

Donc, en ce qui concerne la revendication ".NET est portable", je pense que cela peut être une assertion valable si vous écrivez du code à partir de la base et êtes conscient des problèmes de portabilité avec le cadre. Si l'affirmation est que "j'ai une application Windows écrite en .NET, elle devrait s'exécuter en mono", alors non, ce n'est pas une affirmation valable - mais Mono a fait des efforts pour simplifier le portage de telles applications.

Point par point:

• OpenJDK et tous les JVM fournis par le fournisseur ont réussi le Sun TCK officiel pour s'assurer que tout fonctionne correctement. Je ne suis pas au courant que Mono passe un Microsoft TCK.
  Il existe une spécification à laquelle Microsoft CLR est conforme. Mono n'est pas un clone du CLR de Microsoft, mais une implémentation de cette même spécification. D'un côté, il est possible que cela entraîne une incompatibilité encore plus grande. En pratique, cela a très bien fonctionné pour mono.
• Mono suit les versions .NET. Quel niveau .NET est actuellement entièrement pris en charge?
  Étant donné que la documentation de .Net précède la version actuelle, mono avait terminé la prise en charge (et non une version bêta) de .Net 4 avant la version officielle de Microsoft. De plus, mono documente très bien les éléments qui ne sont pas pris en charge et dispose de quelques outils que vous pouvez exécuter sur le projet existant pour vous aider à identifier les zones potentiellement incompatibles.
• Est-ce que tous les éléments de l'interface graphique (WinForms?) Fonctionnent correctement dans Mono?
  La grande majorité des winforms fonctionne parfaitement. WPF, pas tellement. J'ai entendu dire que la même chose est vraie pour Java: de nombreux toolkits avancés de widgets / interfaces graphiques ne sont pas aussi bien supportés sur toutes les plateformes.
• Les entreprises peuvent ne pas vouloir dépendre des frameworks Open Source en tant que plan officiel B.
  Si tel est le cas, elles ne se lanceront certainement pas dans Java . Dans ce cas, le framework open source est encore plus performant que le plan A.

En résumé, si vous souhaitez créer une application multiplate-forme pour le moment , rien ne vous empêche de commencer par mono dès le début et de l'utiliser comme structure. Vous pouvez même déployer mono sur Windows si vous le souhaitez.

D'autre part, si vous vous cherchez à construire une application de Windows aujourd'hui que vous pensez pourrait devoir être multi - plateforme à un moment inconnu dans l'avenir, vous voudrez probablement aller avec les widgets natifs Windows et des outils. .Net fait ici un bien meilleur travail que Java, et mono est une solution de rechange parfaitement acceptable dans ce scénario.

En d'autres termes: Oui,. Net si multiplate-forme dans tous les sens qui compte pour votre question. Non, mono ne lancera pas tous les programmes .Net immédiatement, mais votre question se situe dans le contexte d'un nouveau projet. Il ne faut pas beaucoup de travail pour éviter les problèmes liés aux nouveaux projets et aux problèmes de compatibilité, en particulier si vous envisagez de développer pour mono plutôt que pour .Net.

Mais surtout, je pense que c’est la mauvaise question en premier lieu. Sauf si vous construisez une nouvelle équipe de développement à partir de rien, vous commencez avec des programmeurs ayant une expertise dans un domaine ou un autre. Vos meilleurs résultats seront obtenus si vous utilisez ce que vos programmeurs savent déjà. Aussi important que de concevoir une application multiplateforme peut sembler, si vous avez une équipe complète de programmeurs .Net avec peu d’expérience java, il est peu probable que vous les fassiez virer ou leur fassiez apprendre le java pour votre prochain projet. Si vous avez une équipe complète de programmeurs Java, vous ne leur demanderez pas d'apprendre. Net pour un projet exclusivement Windows. L'un ou l'autre serait fou.

J'ai travaillé avec Mono, et je dirais que c'est aussi bon que possible avec une plate-forme alternative à code source ouvert, et non directement prise en charge par Microsoft. Si vous pouvez utiliser une autre plate- forme open-source comme Clojure ou Scala, vous pourrez probablement utiliser Mono.

Le niveau de .NET pris en charge par Mono est toujours disponible sur la page Mono Roadmap .

Est-ce que tous les éléments de l'interface graphique fonctionnent? Autant que je sache, ils le font, bien que je n’aie pas essayé de manière exhaustive tous les éléments.

Mono est-il identique à .NET? Non, je soupçonne que des ajustements mineurs (et peut-être majeurs) seront nécessaires ici et là. Vous ne pouvez pas, pour le moment, utiliser Entity Framework avec, par exemple.

En tant que cible, l'univers .NET / mono évolue très rapidement .

Toutes les quelques années, Microsoft propose des changements et des innovations convaincants en ce qui concerne le langage, l'exécution et l'infrastructure entourant .NET. Par exemple: Génériques, LINQ, DLR, Entity Framework - avec chaque nouvelle révision de Visual Studio, il y a généralement une augmentation assez significative de l'ensemble des fonctionnalités et de l'utilité de la structure qu'elle cible.

Bien que l'amélioration constante de la structure soit la bienvenue, il est également problématique si vous souhaitez une compatibilité sur plusieurs plates-formes. Les plates-formes de support à long terme telles que Red Hat Enterprise Linux sont extrêmement lentes en ce qui concerne l'adoption de nouvelles technologies et, à tout moment, des améliorations significatives seront apportées à la plate-forme Mono au cours des derniers mois. Donc, si vous voulez utiliser les éléments que les enfants cool sont en train de construire, vous devrez compiler Mono à partir de rien et gérer vos propres correctifs et mises à jour. C'est pas cool.

Java, en revanche, est aussi stagnant qu'un pool d'enfants. En particulier, maintenant qu’elle appartient à une société qui ne souhaite que Java pour les actions en justice relatives aux brevets, vous pouvez être à peu près certain qu’il n’y aura pas de changements détectables dans la langue ou dans le temps d’exécution dans un avenir proche. Java est une plateforme aussi stable que FORTRAN. Ce n'est pas très bien si vous espériez des améliorations, mais pas si vous essayez de déployer une application d'entreprise.

Du point de vue de l'utilisateur, Mono a du mal à rendre les applications Windows .NET compatibles avec Linux. Si vous essayez d'exécuter une application Windows correctement écrite en Mono, cela ne fonctionnera pas.

Du point de vue du conditionneur (j'avais l'habitude de travailler un peu chez PortableApps), .NET peut être à la fois une bénédiction et une malédiction. Si vous utilisez uniquement Windows, le déploiement de .NET facilite grandement le déploiement car davantage de bibliothèques signifie moins de choses dépendant du système (notamment entre versions de Windows, je crois), mais cela crée également une grande confusion, même sous Windows, car les versions de .NET ne sont pas des versions antérieures. -compatible ou à terme compatible. Vous devez télécharger différentes versions de .NET pour différents programmes.

Cela dit, Mono est un bon point de départ pour rendre les programmes C # inter-plateformes. Il suffit de ne pas empaqueter le programme avec le dernier vin et d'appeler cela fait. Regardez où cela a pris Picasa.

Comme pour la stabilité politique dans les deux langues / plates-formes, RMS commencerait probablement à dire que Mono est dirigé par Novell, dont la lune de miel avec Microsoft est plutôt notoire. Les deux plates-formes peuvent être considérées politiquement instables pour le moment.

Si vous voulez vraiment une multiplate-forme facile, le chemin éprouvé est QT, qui est assez stable politiquement à l’heure actuelle, c’est a) LGPL'd, b) avec ses principaux problèmes de licence depuis des années, et c) avec l’appui de Nokia, qui vend des téléphones vraiment très populaires.

Mono n'est pas un port 1: 1 du .net de Microsoft. Il existe des technologies que Mono ne veut tout simplement pas mettre en œuvre ou ne prévoit pas de faire (par exemple, Workflow Foundation ou WPF ), mais qui possèdent par contre certaines technologies propres à celles de Microsoft .NET, telles que SIMD Extensions. .

Réponse courte: Mono et Microsoft .NET reposent sur la même base sous-jacente - CIL et BCL - mais constituent des projets distincts.

Petit commentaire sur les déclarations de l'article d'origine. Je soutiendrai que le TCK reste un outil théorique permettant à Oracle de prétendre que Java est un standard ouvert. Parce que si vous remarquez, Apache Harmony tente sans succès d'obtenir la certification "Java" depuis plusieurs années. Il est clair que Oracle n'est vraiment pas intéressé par une implémentation open source en dehors de celle à laquelle ils sont affiliés et plus ou moins controlé (OpenJDK), ce qui est d'ailleurs le cas. Tout comme Mono, il n’est pas complet (c’est-à-dire qu’il n’ya pas de support Java Web Start) et il manque certaines optimisations disponibles dans l’implémentation HotSpot à source fermée.

Donc, sans doute, à partir de 2010; (la plupart des) Java est open source mais pas un standard ouvert, alors que (la plupart) des .NET n'est pas open source mais un standard ouvert. Il y a des exceptions bien sûr, le DLR, IronPython, IronRuby et F # sont en fait open source. Mono est intéressant car il fournit le meilleur des deux mondes, des implémentations open source de standards ouverts.

Mis à part toutes les technicités, une partie très importante a lieu lors de l’écriture du code.

Comme avec toutes les technologies multiplates-formes (que ce soit Java, Python, Ruby ...), si le code n'est pas écrit dans un souci de portabilité, vous devez supposer qu'il n'y a aucune chance que le code s'exécute correctement (même si une telle chance est en réalité beaucoup, beaucoup plus haut), dans la mesure où une mauvaise conduite étrange pourrait être assez critique. Lire: ne prenez pas l'assemblage aléatoire et exécutez-le sous Mono.

Pourtant, pour un nouveau projet (ou un projet que vous pouvez facilement refactoriser), choisir .Net / Mono comme runtime potentiellement portable est logique, mais vous évitez bien des soucis en testant votre code sur Mono très tôt, même si le projet a seul un léger changement de multiplateforme. Si vous utilisez un serveur d'intégration continue, cela peut être aussi simple que de configurer un nœud de construction Mono. De nombreux problèmes peuvent être résolus en développant, simplement en en prenant l'habitude (comme de construire des chaînes de chemin) et une grande partie de votre code peut être portable et testée sur Mono en utilisant simplement des pratiques saines et un peu de prévoyance. Le reste (c'est-à-dire les tests unitaires défaillants) est alors spécifique à la plate-forme (comme le code utilisant PInvoke) mais doit être suffisamment encapsulé pour pouvoir fournir une implémentation alternative par plate-forme ciblée.

Bien sûr, l'utilisation d'une bibliothèque non disponible (.Net) ou compatible (tierce partie) dans Mono exclut tout cela, mais dans mon domaine, cela n'a pas encore été vu. C’est la stratégie que nous utilisons réellement au travail, et lorsque je l’applique, je ne crains pas de prétendre que .Net + Mono est multiplate-forme.

Cela varie est la réponse honnête. J'ai vu des petites affaires de serveur Web déplacées d'IIS vers Apache, fonctionnant en mono sans presque aucune difficulté. J'ai exécuté des applications Windows .Net inchangées à l'aide de Win Forms sous Linux.

Cependant, même si cela fonctionne, si vous utilisez un appel API qui n'est pas implémenté en mono, cela ne fonctionnera pas et les seules solutions possibles sont de réécrire votre application, de vous en tenir à Windows ou d'écrire les éléments supplémentaires en mono.