J'ai cru comprendre qu'il était possible avec Mono de faire une application qui n'avait pas besoin du runtime d'installé sur la machine cible, mais qu'il était possible de directement "embarquer" les composants mono necessaires avec le programme lui même.
Est ce que certains d'entre vous ont déja pratiqué ?
Est ce facile à faire ? Sur toutes les plateformes ?
Sous quelle forme se présentent ces composants ?
De plus les applis C# (hors interfaces graphiques) sont elles facilement compatibles Windows/Linux ?
Enfin question subsidiaire: existe t'il un outil pour compiler du C# en natif ?
# Re: C# et Mono
Posté par Epsos . Évalué à 1.
[^] # Re: C# et Mono
Posté par Eric Boulat . Évalué à 1.
[^] # Re: C# et Mono
Posté par TImaniac (site web personnel) . Évalué à 1.
Mono est constitué :
- d'une VM
- d'un JIT
- d'un ensemble de bibliothèque (framework)
le premier élément est indispensable.
le deuxième est inclu dans le premier et te permet de compiler en natif du code IL (qui vient de C# ou autre), mais il te faudra toujours la VM pour effectuer les appels, et "surveiller" le code en cours d'exécution (Garbage Collector etc.). Celà n'a pas beaucoup d'intérêt de compiler en natif, sauf au dernier moment, sur la machine cible (d'où le terme Just In Time, "Just à temps")
Le troisième éléments se décomposent en différents fichiers avec l'extension .dll (ouh vilain mais on s'est d'où celà vient ;)).
Pour les bibliothèques tu peux te contenter de livrer ton application avec les dll dont ton appli dépend (genre system.dll, system.xml.dll, gtk-sharp.dll, etc).
Pour l'exécutable, il n'y a pas de problème, à partir du moment où la VM, bref Mono sait où trouver ce dont il a besoin, cad les lib. Si j'ai bien compris, Mono recherchera d'abord dans un endroit spécifique, dans son dossier lib, à côté de ton appli et dans un dossier lib éventuellement mis à côté de ton appli. Bref, aucun problème. Il te faudra juste faire un petit script pour faire un truc du genre : mono myAppzQuiTue.exe
Par contre ce n'est pas les même VM et bibliothèques de base pour Windows, Linux ou MacOS, because ce n'est pas les même implémentations, donc il faut logiquement "embarquer" des éléments différents. (Sauf ton appli qui elle est indépendante ;))
Voili voilou, j'espère que j'ai répondu à toutes tes questions.
# Re: C# et Mono
Posté par Black Fox . Évalué à 1.
Pour une appli qui n'as pas besoin du runtime je n'en ait jamais entendu parler... tu as pour l'intant toujours besoin d'un framework compatible ECMA .Net ... (C'est à dire actuellement : Celui de Microsoft, Mono ou DotGNU)
Pour la compatibilitée si tu dévelope sous Mono et n'utilise que les classes standardisés (Pas de Microsoft.* ou de System.Windows.*) je n'ai pour l'instant eu aucun problèmes.
[^] # Re: C# et Mono
Posté par Nicolas Antoniazzi (site web personnel) . Évalué à 1.
Je suis allé voir leur site respectif et c'est bien toute les 2 une implantation de .NET ... mais pourquoi faire 2 implantation de la même chose ?
Surtout un truc aussi long a implanter ca... C'est bizarre cette dispersion d'effort.
[^] # Re: C# et Mono
Posté par Erwan . Évalué à 1.
[^] # Re: C# et Mono
Posté par TImaniac (site web personnel) . Évalué à 1.
En fait DotGNU est apparu parcque le projet GNU se devait de ne pas passer à côté de ces techno. Après Wait&See pour voir lequel des 2 sera le plus utilisé, mais y'en a un qui a l'appui de Ximian avec comme chef MDI qui est une forte tête et qui rassemble pas mal de monde en général (pour le meilleur et le pire parfois :) )
[^] # Re: C# et Mono
Posté par Black Fox . Évalué à 1.
- Mono se concentere principalement sur le C# là ou DotGNU essaye de se diversifier
- DotGNU as décidé d'implémenter System.Windows.Forms directement en X11 alors que Mono veut se servir de Wine pour avoir une compatibilitée totale.
Et surtout le point le plus important :
- DotGNU veut créer une implémentation de .Net et c'est tout, là ou Mono veut en faire une plateforme complette et si possible unifiée...
La différence est doc plus philosophique que technique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.