IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

L'intégration du compilateur Roslyn à Mono avance à grands pas ,
Le moteur Roslyn soutenant les EDI de Mono bientôt disponible pour des tests

Le , par Olivier Famien

95PARTAGES

1  0 
Depuis la mise à disposition de Roslyn en tant que compilateur open source, une porte a été largement ouverte aux développeurs afin de bénéficier des avantages liés à ce compilateur. Mono, qui est un projet dérivé de la plateforme .Net avec pour mission de permettre le développement de projet C# pour les plateformes Linux, iOS et Android, s’est également rapproché de ce compilateur.

Ainsi depuis 2014, Miguel de Icaza fondateur de Mono et également directeur de technologie de Xamarin et son équipe ont travaillé de manière acharnée dans le but de remplacer le moteur de Xamarin Studio et MonoDevelop par Roslyn, ainsi que de faire de Roslyn le compilateur principal de Mono. Après une année de dur labeur, Miguel vient nous donner les résultats des travaux de son équipe.

De prime abord, il faut savoir que les environnements de développement Xamarin Studio et MonoDevelop sont soutenus par le moteur NRefactory et le compilateur Mono C#. C’est lui qui permet d’effectuer la complétion de code, le refactoring, des suggestions et le formatage de code.

Celui-ci présentant des limites vis-à-vis de Roslyn, Miguel et son équipe ont mis en œuvre une branche bénéficiant des fonctionnalités de Roslyn. Ils ont également profité pour porter la plupart des capacités de refactoring de NRefactory pour qu’elles puissent tourner au-dessus de Roslyn.

Toutefois, après avoir effectué des tests, il s’avère que la branche Roslyn qui a été conçue présente des fuites de mémoire dues à des bogues dans le code sous-jacent.

Miguel soutient que « notre plan initial était de sortir celui-ci pour notre version de septembre (ce que nous appelons en interne “’ Cycle 6’’), mais nous avons décidé de retirer la fonctionnalité da la publication pour nous donner du temps pour réparer les fuites qui ont affecté le moteur et régler les performances de Roslyn fonctionnant sur Mono ».

Après cette annonce, certains pourraient se laisser aller au découragement, mais ils ne devraient pas. En effet, bien que le cycle 6 sortira sans la branche de Roslyn, l’équipe en charge du projet sortira concomitamment un moteur soutenant les EDI avec Roslyn activé. Ceux qui sont intéressés pourront donc procéder à des tests et envoyer des retours à l’équipe de développement afin de corriger les bugs. L’objectif à terme est d’adopter définitivement ce moteur.

Pour ce qui concerne l’intégration de Roslyn dans Mono, l’objectif principal est de fournir des informations de débogage lors de l’utilisation de ce compilateur sur Unix. Sur Windows, la génération de ces informations est effectuée par une bibliothèque native qui est incompatible avec Unix.

Jusqu’alors, c’était un véritable problème. Les choses ayant évolué, Roslyn peut maintenant générer ces informations de débogage pouvant être utilisées par Mono. Cette étape a pu être franchie grâce support apporté au format PPDB (Portable Program Database) qui est un est format de fichiers encodés pour recevoir les informations de débogage produites par les compilateurs des langages CLI.

Toutefois, il faut également retenir que des efforts sont encore à faire afin que Roslyn puisse entièrement être intégré à Mono. Depuis le support des fichiers PPDB, des bugs ont pointé du nez. L’équipe de développement est à pied d’œuvre afin de corriger ces bugs qui dans beaucoup de cas ont pu être résolus en remplaçant l’implémentation de Mono avec celles de la source de référence de Microsoft.

Source : Blog de Miguel de Icaza

Et vous ?

Que pensez-vous de ces avancées ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 25/07/2015 à 16:44
Citation Envoyé par Aeson Voir le message
Je ne comprend pas pourquoi ce projet continue a exister et surtout pourquoi ils investissent encore dedans.

Microsoft publie de plus en plus le code de .Net en open source sur Github. Et on sait qu'a terme tous ce que Mono a fait sera disponible en version original fourni par Microsoft.

https://github.com/aspnet/Home/wiki/Roadmap

Le 24 août sortira l’environnement d’exécution de la CoreClr sur Linux et Mac donc a quoi sert Mono ? (Sachant que Mono n’inclus pas l'asynchrone ni WPF)
Oui mais mono gère d'autre techno d'UI, le coreClr+fx qui va sortir ne sera pas complet et surtout orienté Web.
D'autre part le 24 aout ,c'est une bêta qui va sortir.

C'est une bonne chose le portage de .NET , mais sans le tooling ils vont avoir du mal à concurrencer Java qui pourtant stagne un peu.
1  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 25/07/2015 à 17:13
Citation Envoyé par Aeson Voir le message
(Sachant que Mono n’inclus pas l'asynchrone ni WPF)
Mono inclut bien l'asynchrone, et .NET Core n'inclut pas non plus WPF. WPF est intrinsèquement lié à Windows (à cause de l'utilisation intensive de DirectX), donc ce ne sera jamais portable.
0  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 25/07/2015 à 17:20
Citation Envoyé par tomlev Voir le message
Mono inclut bien l'asynchrone, et .NET Core n'inclut pas non plus WPF. WPF est intrinsèquement lié à Windows (à cause de l'utilisation intensive de DirectX), donc ce ne sera jamais portable.
oui, mais en rêvant un peu, le principe serait portable ( avec beaucoup d'huile de coude).
Tu regardes , Java FX fonctionne bien sur Linux.

En gros faudra un WPF 2.0 remanié quitte a perdre la compatibilité des applis existantes...

Ils veulent miser tout sur le web...
0  0 
Avatar de Aeson
Nouveau Candidat au Club https://www.developpez.com
Le 25/07/2015 à 17:32
Citation Envoyé par tomlev Voir le message
Mono inclut bien l'asynchrone, et .NET Core n'inclut pas non plus WPF. WPF est intrinsèquement lié à Windows (à cause de l'utilisation intensive de DirectX), donc ce ne sera jamais portable.
Je parle du Pipeline async web :

http://www.mono-project.com/docs/about-mono/compatibility

Il faudra voir ce que mono apporte de plus comparé a la CoreClr + DNX + ASP.Net 5. A mon avis rien ou pas grand chose.
0  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 26/07/2015 à 12:03
Citation Envoyé par Aeson Voir le message
Ah oui, c'est vrai. Je fais pas de dev web, donc j'ai tendance à l'oublier
0  0 
Avatar de Aeson
Nouveau Candidat au Club https://www.developpez.com
Le 25/07/2015 à 14:12
Je ne comprend pas pourquoi ce projet continue a exister et surtout pourquoi ils investissent encore dedans.

Microsoft publie de plus en plus le code de .Net en open source sur Github. Et on sait qu'a terme tous ce que Mono a fait sera disponible en version original fourni par Microsoft.

https://github.com/aspnet/Home/wiki/Roadmap

Le 24 août sortira l’environnement d’exécution de la CoreClr sur Linux et Mac donc a quoi sert Mono ? (Sachant que Mono n’inclus pas l'asynchrone ni WPF)
0  2