Mono est fréquemment utilisé pour dire "Oui, .NET est multiplateforme". Quelle est la validité de cette réclamation?

Question

In Que choisiriez-vous pour votre projet entre .NET et Java à ce stade? Je dis que je considérerais le "Allez-vous toujours déployer sur Windows? "la décision technique la plus importante à prendre en main 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 jamais nous voulons exécuter sur Linux/OS X/peu importe, nous allons simplement exécuter Mono"¹, qui est un argument très convaincant à première vue, mais je ne suis pas d'accord pour plusieurs raisons.

OpenJDK et toutes les JVM fournies par le fournisseur ont passé le Sun TCK officiel garantissant que les choses fonctionnent correctement. Je ne suis pas au courant que Mono a réussi un Microsoft TCK.
Mono suit les versions .NET. Quel niveau .NET est actuellement entièrement pris en charge?
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 n'est pas sûr, mais par exemple IBM fournit des JDK pour de nombreuses plates-formes , y compris Linux. Ils ne le sont tout simplement pas open source.

Alors, dans quelles circonstances Mono est-il une stratégie commerciale valable pour les applications .NET?

¹_{Mark H l'a résumé comme suit : "Si la réclamation est que " J'ai une application Windows écrite en .NET, elle devrait fonctionner en mono ", alors non, ce n'est pas une affirmation valable - mais Mono a fait des efforts pour simplifier le portage de telles applications. "}

miguel.de.icaza · Accepted Answer

réponse de Sparkie compris, permettez-moi de compléter un peu.

".NET est multiplateforme" est une déclaration trop ambiguë car le cadre et le monde pour lequel il a été créé à l'origine 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 multiplateforme et, comme si vous voulez faire passer votre code sur plusieurs plates-formes, vous devez planifier l'utilisation les bonnes API sur la bonne plateforme pour offrir la meilleure expérience sur chaque plateforme.

La famille CLI n'a pas essayé l'approche "Write Once, Run Anywhere", car les différences entre un téléphone et un ordinateur central sont trop importantes. Au lieu de cela, un univers d'API et de fonctionnalités d'exécution spécifiques à la plate-forme a émergé pour donner aux développeurs les bons outils pour créer de grandes expériences dans chaque plate-forme.

Pensez-y: les programmeurs ne ciblent plus les PC Windows ou les serveurs Unix. Le monde, aujourd'hui plus que jamais, est entouré de plates-formes fascinantes, des PC aux consoles de jeu, 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 se sentirait simplement gonflée sur de petits appareils et se sentirait sous-alimentée sur les grands systèmes .

Le produit .NET Framework de Microsoft n'est pas multiplateforme, il ne fonctionne que sur Windows. Il existe des variantes du .NET Framework de Microsoft qui s'exécutent sur d'autres systèmes comme le Windows Phone 7, le XBox360 et les navigateurs via Silverlight, mais ce sont tous des 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 grand public avec des technologies basées sur .NET. Voici une liste qui montre quelle implémentation CLI vous utiliseriez dans chaque cas (cette liste n'est pas exhaustive, mais devrait couvrir 99% des cas):

ordinateurs PC x86 et x86-64:
- sous Windows -> En règle générale, vous exécutez .NET ou Silverlight, mais vous pouvez également utiliser Mono complet ici.
- sous Linux, BSD ou Solaris -> Vous exécutez Full Mono ou Silverlight
- exécutant MacOS X -> vous exécutez Mono ou Silverlight complet
- en cours d'exécution Android -> Vous exécutez le sous-ensemble Mono/Android
Ordinateurs ARM:
- Exécution de Windows Phone 7: vous exécutez Compact Framework 2010
- Sous Windows 6.5 et versions antérieures: vous exécutez l'ancien Compact Framework
- Appareils Android: vous exécutez Mono/Android
Ordinateurs PowerPC:
- Vous exécutez Mono complet pour les systèmes d'exploitation Linux, BSD ou Unix complets
- Vous exécutez Mono intégré pour PS3, Wii ou d'autres systèmes intégrés.
- Sur XBox360, vous exécutez CompactFramework
S390, S390x, Itanium, SPARC:
- Vous exécutez Mono complet
Autres systèmes d'exploitation intégrés:
- Vous exécutez .NET MicroFramework ou Mono avec le profil mobile.

Selon vos besoins, ce qui précède peut être suffisant ou non. Vous aurez à peine le même code source à exécuter partout. Par exemple, le code XNA ne s'exécutera pas sur chaque bureau, tandis que le logiciel .NET Desktop ne s'exécutera pas sur XNA ou sur le téléphone. Vous devez généralement apporter des modifications à votre code pour qu'il s'exécute 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
Profil mono core - suit le profil .NET et est disponible sur Linux, MacOS X, Solaris, Windows et BSD.
.NET Micro Framework
Mono sur le profil iPhone
Mono sur Android Profile
Mono sur profil PS3
Mono sur le profil Wii
Profil Moonlight (compatible avec Silverlight)
Profil étendu Moonlight (Silverlight + accès complet à l'API .NET 4)

Donc, chacun de ces profils est en fait légèrement différent, et ce n'est pas une mauvaise chose. Chaque profil est conçu pour tenir sur sa plate-forme hôte et exposer les API qui ont du sens, et supprimer celles qui n'ont pas de sens.

Par exemple, les API Silverlight pour contrôler le navigateur hôte n'ont pas de sens sur le téléphone. Et les shaders dans XNA n'ont aucun sens sur le matériel PC qui n'a pas le support équivalent pour cela.

Plus tôt vous réaliserez 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é sur Windows, Linux, Solaris, MacOS X car ces API existent à la fois sur .NET et Mono. ASP.NET n'est pas disponible sur certaines plates-formes prises en charge par Microsoft comme XBox ou Windows Phone 7 et n'est pas pris en charge sur les autres plates-formes prises en charge par Mono comme la Wii ou l'iPhone.

Les informations suivantes ne sont correctes qu'au 21 novembre, et de nombreuses choses dans le monde mono changeront probablement.

Les mêmes principes peuvent être appliqués à d'autres piles, une liste complète nécessiterait un tableau approprié, que je n'ai aucune idée de la façon de 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 ne figure pas ici est disponible (n'hésitez pas à m'envoyer des modifications pour les choses que j'ai manquées):

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]
Déchargement d'assembly [Windows uniquement]
Injection de VM [Linux, BSD, MacOS X, Solaris]
DLR [Windows, Linux, MacOS X, Solaris, MonoDroid]
Génériques [quelques limitations sur PS3 et 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 de base [partout]
- Sérialisation XML [partout, sauf WP7, CF, Xbox)
LINQ to XML (partout)
System.Json [Silverlight, Linux, MacOS, MonoTouch, MonoDroid]
System.Messaging [Windows; sous Linux, MacOS et Solaris nécessite RabbitMQ]
Services d'entreprise .NET 1 [Windows uniquement]
WCF [complet sur Windows; petit sous-ensemble sur Silverlight, Solaris, MacOS, Linux, MonoTouch, MonoDroid]
Flux de travail Windows [Windows uniquement]
Identité de l'espace de cartes [Windows uniquement]

Piles GUI

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

Bibliothèques graphiques

GDI + (Windows, Linux, BSD, MacOS)
Quartz (MacOS X, iPhone, iPad)
Le Caire (Windows, Linux, BSD, MacOS, iPhone, iPad, MacOS X, PS3, Wii)

Bibliothèques mono - multiplateforme, peuvent être utilisées dans .NET mais nécessitent une construction manuelle

Compilateur C # 4 en tant que service
Cecil - CIL Manipulation, workflow, instrumentation de CIL, Linkers
Bibliothèques RelaxNG
Fournisseurs de bases de données Mono.Data. *
System.Xaml complet (à utiliser dans les configurations où .NET n'offre pas la pile)

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

Je m'excuse pour le manque de formalité.

Mark H · Answer

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

Je ne sais pas si Microsoft a un outil pour valider qu'une implémentation est conforme, mais s'ils le font, je suis presque sûr que les gars 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 .NET actuelle). De plus, Microsoft a récemment rendu tous les codes et bibliothèques DLR open source (sous la licence Apache 2.0), ce qui a permis à mono d'utiliser des langages comme 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 de se tenir à jour avec les versions actuelles.

Il existe un certain nombre d'outils et d'extensions dans .NET, par exemple, les contrats de code. Ceux-ci ne sont pas toujours entièrement implémentés 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, le taux de mise en œuvre en mono en serait de même.

Les 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 multiplateformes (GTK # et Silverlight). Si vous écriviez une application à partir de zéro avec la portabilité à l'esprit, vous utiliseriez l'un de ceux-ci plutôt que Winforms/WPF. De plus, mono fournit un wrapper fin pour l'API Winforms - qui permet aux applications winforms existantes d'être portées plus facilement dans GTK # (sans réécriture complète).

Mono fournit un outil, le Mono Migration Analyzer (MoMA), qui peut prendre une application .Net existante et vous parler de sa portabilité. (par exemple, identifier les bibliothèques non portables qui sont utilisées, P/Invokes, etc.).

Pour les entreprises qui ne veulent pas dépendre de l'Open Source - mono peut être sous licence. La propriété du code ajouté à mono est transférée à novell, qui peut le concéder sous d'autres formes que la licence LGPL habituelle (qui a 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 affirmation valide si vous écrivez du code à partir de zéro et que vous êtes conscient des problèmes de portabilité avec le framework. Si l'affirmation est que "j'ai une application Windows écrite en .NET, elle devrait fonctionner en mono", alors non, ce n'est pas une revendication valide - mais Mono a fait des efforts pour simplifier le portage de telles applications.

Joel Coehoorn · Answer

Point par point:

OpenJDK et toutes les machines virtuelles Java fournies par le fournisseur ont passé le Sun TCK officiel pour s'assurer que les choses fonctionnent correctement. Je ne suis pas au courant que Mono passe un Microsoft TCK.
Il existe une spécification à laquelle le Microsoft CLR est conforme. Mono n'est pas un clone du CLR de Microsoft, mais plutôt une implémentation de cette même spécification. D'une part, il y a une chance que cela se traduise par une incompatibilité encore plus grande. En pratique, cela a très bien fonctionné pour le mono.
Mono suit les versions de .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 en fait terminé (pas une version bêta) la prise en charge de .Net 4 out avant la version officielle de Microsoft. De plus, mono fait un très bon travail de documentation des choses qui ne sont pas prises en charge, et ils ont quelques outils que vous pouvez exécuter sur un projet existant pour vous aider à repérer les endroits avec le potentiel d'incompatibilité.
Tous les éléments de l'interface graphique (WinForms?) Fonctionnent-ils correctement en Mono?
La grande majorité des winforms fonctionne très bien. WPF, pas tellement. J'ai entendu dire que la même chose est vraie pour Java - de nombreuses boîtes à outils avancées de widget/gui ne sont pas aussi bien prises en charge sur toutes les plateformes.
Les entreprises peuvent ne pas vouloir dépendre des frameworks Open Source comme le plan officiel B.
Si c'est le cas, ils n'iront certainement pas avec Java, alors, car cela place un cadre open source encore plus haut dans le plan A.

En résumé, si vous souhaitez créer une application multiplateforme en ce moment , il n'y a rien de mal à commencer par mono dès le départ et à l'utiliser comme votre cadre. Vous pouvez même déployer mono sur Windows si vous le souhaitez.

D'un autre côté, si vous envisagez de créer une application Windows aujourd'hui que vous pensez pourrait avoir besoin d'être multiplateforme à un moment inconnu dans le À l'avenir, vous voudrez probablement utiliser les widgets et les outils natifs de Windows. .Net fait un bien meilleur travail ici que Java, et le mono est une solution de repli parfaitement acceptable dans ce scénario.

En d'autres termes: Oui, .Net si multiplateforme de toutes les manières qui comptent pour votre question. Non, mono n'exécutera pas tous les programmes .Net prêts à l'emploi, mais votre question se situe dans le contexte d'un nouveau projet. Il ne faut pas beaucoup de travail pour garder les nouveaux projets à l'abri des problèmes et éviter les problèmes de compatibilité, surtout si vous pensez en termes de développement pour mono plutôt que de développement pour .Net.

Mais surtout, je pense que ce n'est pas la bonne question en premier lieu. Sauf si vous construisez une nouvelle équipe de développement à partir de zéro, vous commencez avec des programmeurs qui ont une expertise dans un domaine ou un autre. Vos meilleurs résultats seront obtenus en suivant ce que vos programmeurs savent déjà. Aussi important que la construction d'une application multiplateforme puisse sembler, si vous avez une équipe pleine de programmeurs .Net avec peu d'expérience Java, il est peu probable de les déclencher ou de les faire tous apprendre Java pour votre prochain projet. Si vous avez une équipe de programmeurs Java, vous ne leur demanderez pas d'apprendre .Net pour un projet Windows uniquement. L'un ou l'autre serait fou.

Robert Harvey · Answer

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

Le niveau de .NET pris en charge par Mono peut toujours être trouvé sur la page Mono Roadmap .

Tous les éléments de l'interface graphique fonctionnent-ils? Pour autant que je sache, ils le font, même si je n'ai pas essayé tous les éléments de manière exhaustive.

Mono est-il identique à .NET? Non. Je suppose qu'il y aura des ajustements mineurs (et peut-être majeurs) requis ici et là. Par exemple, vous ne pouvez pas actuellement exécuter Entity Framework avec.

tylerl · Answer

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

Toutes les quelques années, Microsoft propose des changements et des innovations convaincants concernant le langage, le temps d'exécution et l'infrastructure entourant .NET. Par exemple: Generics, LINQ, DLR, Entity Framework - avec chaque nouvelle révision de Visual Studio, il y a généralement une augmentation assez importante de l'ensemble de fonctionnalités et de l'utilité du framework qu'il cible.

Bien que l'amélioration constante du cadre soit bienvenue, elle est également problématique si vous souhaitez la compatibilité entre plusieurs plates-formes. Les plates-formes de support à long terme comme Red Hat Enterprise Linux évoluent de manière extrêmement lente en ce qui concerne l'adoption de nouvelles technologies, et à tout moment, des améliorations significatives de la plate-forme Mono se sont produites au cours des derniers mois. Donc, si vous voulez exécuter les choses que les enfants cool construisent, vous devrez compiler Mono à partir de zéro et gérer vos propres correctifs et mises à jour. Ce n'est pas cool.

Java, d'autre part, est aussi stagnant qu'un bassin pour enfants. Surtout maintenant qu'il appartient à une entreprise qui voulait juste Java pour les poursuites en matière de brevets, vous pouvez être assez certain qu'il n'y aura pas de changements détectables dans la langue ou le runtime dans un avenir prévisible. Java est une plate-forme aussi stable que FORTRAN. Ce n'est pas si bon si vous espériez une sorte de améliorations, mais pas si mal si vous essayez de déployer une application d'entreprise.

digitxp · Answer

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

Du point de vue d'un emballeur (j'avais l'habitude de faire un peu de travail chez PortableApps), .NET peut être à la fois une bénédiction et une malédiction. Si vous êtes uniquement sur Windows, .NET facilite le déploiement car plus de bibliothèques signifie moins de choses dépendantes du système (notamment entre les versions de Windows, je crois) mais est également extrêmement déroutant même sur Windows car les versions .NET ne sont ni à l'envers -compatible ou compatible vers l'avant. 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 créer des programmes C # multiplateforme. Il suffit de ne pas empaqueter le programme avec le dernier WINE et de l'appeler terminé. Regardez où cela a amené Picasa.

Comme pour la stabilité politique des deux langues/plates-formes, RMS commencerait probablement à se plaindre de la façon dont Mono est dirigé par Novell, dont la lune de miel avec Microsoft est assez notoire. Les deux plates-formes peuvent être considérées comme politiquement instables en ce moment .

Si vous voulez vraiment une plate-forme simple, la voie éprouvée est QT qui est assez stable politiquement à l'heure actuelle, c'est a) LGPL'd, b) fait avec ses principaux problèmes de licence des années passées, et c) soutenu par Nokia, qui vend des téléphones vraiment très populaires.

Michael Stum · Answer

Mono n'est pas un port 1: 1 du .net de Microsoft. Il existe des technologies que Mono n'implémentera tout simplement pas ou n'a pas l'intention de le faire (par exemple, Workflow Foundation ou WPF ) tandis que d'autre part, ils en ont technologies propres que Microsoft .NET ne fait pas, par exemple, les extensions SIMD.

Réponse courte: Mono et Microsoft .NET sont basés sur la même fondation sous-jacente - CIL et BCL - mais sont des projets distincts.

Casper Bang · Answer

Petit commentaire sur les déclarations dans le post 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 le constatez, Apache Harmony essaie depuis plusieurs années d'obtenir la certification "Java", sans succès. Il est clair qu'Oracle n'est vraiment pas intéressé par une implémentation open source en dehors de celle avec laquelle ils sont affiliés et qui contrôle plus ou moins (OpenJDK), qui d'ailleurs. tout comme Mono, n'est pas complet (c.-à-d. pas de prise en charge de Java Web Start) et manque certaines optimisations disponibles dans l'implémentation HotSpot en source fermée.

Sans doute, à partir de 2010; (la plupart) Java est open source mais pas un standard ouvert, tandis que (la plupart) .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 offre le meilleur des deux mondes, des implémentations open source de standards ouverts.

Lloeki · Answer

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

Comme avec toute technologie multiplateforme (que ce soit Java, Python, Ruby ...), si le code n'est pas écrit avec la portabilité à l'esprit, vous devez supposer qu'il n'y a pratiquement aucune chance que le code s'exécute correctement (même si une telle chance est en réalité beaucoup, beaucoup plus élevé), car 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 que vous pouvez facilement refactoriser), choisir .Net/Mono comme un runtime potentiellement portable a du sens, mais vous vous épargnez beaucoup de tracas en testant votre code sur Mono très tôt, même si le projet a seulement 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 génération Mono. De nombreux problèmes peuvent être résolus pendant le développement, juste en prenant l'habitude (comme la construction de chaînes de chemin) et une grande partie de votre code peut être portable et testée sur Mono simplement en utilisant des pratiques sensées et un peu de prévoyance. Le reste (c'est-à-dire l'échec des tests unitaires) 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. De cette façon, lorsque le projet finit par être porté, une bonne partie du travail a été effectuée presque gratuitement et le reste doit être développé Just In Time.

Bien sûr, l'utilisation d'une bibliothèque non disponible (.Net) ou compatible (tiers) dans Mono empêche 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 n'ai aucune crainte de prétendre que .Net + Mono est multiplateforme.

Michael Shaw · Answer

Cela varie est la réponse honnête. J'ai vu de petites choses de serveur Web déplacées de IIS vers Apache, fonctionnant sous mono avec presque aucune difficulté. J'ai exécuté des applications Windows .Net inchangées en utilisant Win Forms sur Linux avec succès.

Cependant, même si cela peut fonctionner, si vous utilisez un appel d'API qui n'est pas implémenté en mono, cela ne fonctionnera pas, et les seules solutions sont de réécrire votre application, de rester avec Windows ou d'écrire les trucs supplémentaires en mono.