Je sais que l'inverse n'est pas vrai, mais si mon application fonctionne à l'aide de mono, il est garanti de fonctionner si je passe à la vraie affaire? Sinon, où puis-je trouver une liste de mises en garde?
4 Réponses :
non. Mono comprend plusieurs cadres d'interface utilisateur alternative (GTK #, WXWindows pour .NET, etc.).
Si vous utilisez uniquement des cours définies par Microsoft, cependant, allez-vous bien.
mono est une implémentation du CLI Standard, de même que le CLR .
Il inclut de nombreuses bibliothèques que vous trouverez dans la BCL .NET, mais aucune spécifique Windows (WMI est un domaine entier qui vous vient à l'esprit).
Tant que vous gardez les fonctionnalités qui ne sont pas spécifiques à Windows, vous devriez être bien.
L'équipe mono a créé un outil pour vérifier si votre code devrait fonctionner sur mono- MOMA , l'analyseur de migration mono.
Autant qu'utilisez le code mono avec les compilateurs Microsoft, vous devez également inclure les bibliothèques que vous utilisez et ne faites pas de pinvokes sur Linux, vous devriez être bien.
Je parle de l'inverse.
Mono n'exprime pas les API de BCL, du moins pas dans le système . Par conséquent, vous pouvez être tout à fait certain qu'une application utilisant uniquement des types de l'espace de noms (code> sera portable sans recompilation de mono à .NET. Bien sûr, vous ne trouverez rien dans l'espace de noms mono une fois que vous êtes dans le monde .net.
du Mono FAQ :
Prévoyez-vous embrasser et étendre .NET?
embrasser une bonne technologie est bon. Extension des technologies en incompatibilité façons est mauvais pour les utilisateurs, donc nous faisons pas planifier la fabrication incompatible modifications apportées aux technologies.
Si vous avez des idées innovantes et que vous voulez Pour créer de nouvelles classes, nous encourageons vous faire fonctionner ces cours correctement bien dans mono et .net. Aujourd'hui, Mono est expédié avec un certain nombre de bibliothèques supplémentaires qui ont été développées soit par des membres du mono communauté ou d'autres groupes.
dans certains cas, nous avons trouvé les bits de Microsoft sera incomplet, mais nous Évitez de briser l'API, à la place nous exposer la fonctionnalité manquante dans Nouveaux assemblages (voir mono.security)
+1, c'est un point important que j'ai oublié de mentionner dans ma réponse: presque toutes ces extensions "propriétaires" L'équipe mono a fait, étaient sous forme de bibliothèque, de sorte qu'ils travaillent également sur .NET. Les continuations, par exemple, ont un support VM à Mono, mais ils travaillent également sur .NET. Ils sont beaucoup trop lents à être réellement utilisables, mais ils font travail (pour une définition assez généreuse de "travail", au moins.) Le C # Remplement, qui a utilisé directement le compilateur mono directement, est actuellement en Le processus d'être rétabli sur réflexe.emit . La seule chose qui ne peut pas être prise en charge sur .NET, est mono.simd .
J'ai confondu Simd et continuations. En fait, c'est l'inverse: SIMD fonctionne sur .NET, en émulant les instructions SIMD au niveau de la CPU en C #. Les continuations ne font pas, car elles nécessitent un soutien de continuation au niveau VM.
Les deux mono et .NET sont des supersets de la famille des spécifications de l'ECMA / ISO CLI. Cependant, ni .net ni mono ne sont sous-ensembles de l'autre. Mono et .NET Ajoutez des fonctionnalités au-dessus de l'ECMA / ISO CLI, mais tandis que MONO implémente de nombreux ajouts de .NET, .NET n'entraîne aucun des ajouts de Mono.
Voici quelques exemples:
Note, cependant, que (à l'exception des tableaux), toutes ces espaces de noms sont clairement distinctes, car aucun d'entre eux ne vivent dans le système Edit: En réalité, la plupart des extensions mentionnées ci-dessus sont explicitement conçues pour fonctionner également sur .NET. Par exemple, Seuls uniquement la bibliothèque système ou Microsoft Microsoft .
mono.simd fonctionne également sur .NET, mais sans le support d'exécution que le mono VM a, c'est inopportun. (Fondamentalement, toutes les opérations SIMD sont implémentées dans C #, mais le compilateur mono détecte ces appels et les remplace avec leurs instructions de montage correspondantes. De cette façon, ils travaillent sur .NET, mais sans traitement spécial, ils sont nettement plus lents.) , le C # Remm est en cours de rétablissement sur reflet.emit (pour le moment, il appelle directement le compilateur mono directement), de sorte qu'il fonctionnera sur .NET dans le futur. GTK # fonctionne bien sur Windows et .NET.
mono.taklet ne peut pas être implémentée sur .NET, car elle nécessite une prise en charge au niveau de la VM pour la poursuite.
MONO.SIMD fonctionne cependant sur le .NET Runtime, car elle revient au logiciel.
@Matt Olenik: Merci. Apparemment, j'ai confondu Simd et continuations. SIMD fonctionne, mais est lent, mono.taklet n'a pas '.