DBus avec .Net

Pour ceux qui ne le savent pas, je travail sur un serveur d’application .Net indépendant de la plateforme Windows: DotNetServer.

Après une version bonne pour une démo, j’ai voulu refactoriser le tout pour avoir quelque chose de viable.
Dans mon dernier billet, j’explique mon périple à la recherche d’un protocole de communication Inter-Processus, et j’ai choisi NDesk.DBus: l’implémentation full .Net de D-Bus.

La solution était sexy:

  • Déclaration des services par interface, ne pouvant exposer QUE des types simples ou Struct. Cela force à réaliser qu’en matière de communication, une instance d’objet ne veut rien dire et qu’on communique que par DTO.
  • Support des méthodes, propriétés et événements
  • Channel par Socket/TCP ou par Pipe
  • Communication optimisé binaire (pas d’XML ou de SOAP….)
  • Exposition des services sur le Bus avec un contrat au format XML (comme un WSDL en quelque sorte)
  • Cross-platform: provient du monde Linux mais existe sous Windows
  • Un standard de communication Inter-Processus, de plus en plus utilisé sous Linux, remplaçant CORBA (avec Bonobo)

Mais voila, tout n’est pas rose, et DBus me donne du fil à retorde.
L’implémentation .Net n’est pas très propre:

  • API pas très utilisable car quasiment tout est Internal
  • Pas de doc?
  • Ça manque de convention, le source n’est pas très lisible, j’ai envie de passer un coup de Resharper dessus :)
  • Beaucoup, beaucoup de commentaire du genre « //temporary hack » ou « //TODO« … beaucoup de code commenté qui prouve que la personne a voulu faire bien mais n’a pas eu le temps
  • Quand j’exécute DBusExplorer pour scanner mes services, cela plante 1 fois sur 2 mon client
  • Je n’arrive pas à faire marcher un service ou un client dans un Thread!!! Cela me bloque totalement

Je me demande si je ne vais pas revenir à une solution .Net Remoting:

  • implémentation .Net et Mono
  • channel IPC (par Pipe)
  • supporte les événements
  • DBus est vraiment orienté « Desktop » comme le D l’indique. J’en fait donc une utilisation détournée.

Mais une autre solution peut aussi faire l’affaire: ProtoBuf, un protocole performant inventé par Google.

Je vais tacher de vous tenir plus au courant, histoire aussi de recueillir des opinions concernant mes choix.

DotNetServer

Comme je tarde à sortir mes posts sur les Techdays (et d’autres sujets, haha, surprise!), je vais en sortir un « tout petit ».

Pas de conteneur d’application en .Net… ou presque

En fait, c’est suite à une frustration absolue datant du premier jour ou j’ai découvert .Net (car je faisais du Java, avant, dans mon temps libre…).
Après avoir lourdement digéré J2EE, les EJB, RMI/IIOP, j’ai été déçu de ne rien voir de tel en .Net.
Certains dirait que ce n’est pas une grosse perte ;) En effet, J2EE n’a rien de simple, mais c’est quand même parfois puissant.

Je trouve stressant qu’une application .Net « d’entreprise » doit forcement dépendre des services Windows, des tâches schédulées, ou d’IIS. Déployer une application Java sur Tomcat est d’une simplicité déconcertante, et Microsoft propose un équivalent seulement dans le future Windows Server 2008 R2 avec Windows AppFabric.
Et encore, pour avoir vu la présentation aux Techdays, je suis plutôt déçu.
Lire la suite

Java for iPhone

Pour les fans de .Net et de l’iPhone, vous savez sans doute que vous pouvez vous éclater avec MonoTouch.
J’en profite pour dire que JB Evain en parlera aux TechDays.

La particularité et le défi de MonoTouch, c’est que le processeur de l’iPhone ne supporte pas une opération nécessaire à la compilation à chaud (JIT), qui est la base des langages sur une VirtualMachine (.Net et Java). L’application Mono est alors compilée nativement, avec une suppression des bibliothèques du framework inutilisées.

Et Java alors, est-ce que la communauté compte faire quelque chose?
Et bien une startup, Flexycore, l’a déjà fait: iSpectrum! Et le produit est gratuit pour les projets Open-Source!!! Ce qui n’est pas le cas pour MonoTouch.

Voici un aperçu de ce qui est possible:

Certes, la démo n’est pas « bandante », mais derrière, il y a le support de J2ME, du JavaScript, les API de l’iPhone (comme le GPS) et bientôt l’API OpenGL ES.
Est-ce le retour de Java pour les jeux mobiles?

Hudson + Gendarme!

Petit billet pour vous annoncer fièrement la sortie de la version 0.7.5 du plugin « Violation » pour Hudson: http://wiki.hudson-ci.org/display/HUDSON/Violations

J’y ai notamment contribué pour ajouter le support de Gendarme, l’outil d’analyse de code de Mono (équivalent à FXCop/StyleCop).
J’aurais aimé y contribué plus que cela (si j’avais eu le temps…) pour par exemple corriger les bugs sous IE ou les bugs sur les rapports FXCop/StyleCop avec des chemins relatifs.
Ces corrections de bugs me serrait très utiles dans le cadre de mon projet chez mon Client, puisque nous avons fait le choix d’utiliser Hudson comme plateforme d’intégration continue « multi-techno » (Java/C#/C++/Php).

Même si les développeurs Java exploite Hudson avec Sonar pour avoir un beau Dashboard sur des métriques de codes sources, nous exploitons les plugins d’Hudson pour les métriques .Net. En effet, le plugin Violation nous permet d’avoir des graph et des seuils d’alerte sur les rapports FXCop & Style. Nous combinons ça au plugin de rapport de tests NUnit, le plugin de rapport de tests Selenium, ainsi que le plugin Warning pour analyser les Warnings/Error à la compilation, et le plugin Task Scanner pour ne pas oublier de TODO dans le code ;) En plus de cela, on génère un rapport NCoverExplorer (HTML) accessible directement depuis Hudson.

Et vous? Comment faites-vous vos métriques dans l’intégration continue? Est-ce que vous connaissiez Gendarme et est-ce que vous l’avez déjà utilisé?

Mono : nouveau standard ?

Pour ce qui ne sont pas au courant ou qui n’aurai pas vu la vidéo de la PDC, voici l’article d’InfoQ sur Mono.Simd.
J’aime bien le titre « Mono: Going Beyond the Standard », et c’est de ça que je vais parler…

J’ai posé la question lors de la soirée ALT.Net en présence de Jean-Baptiste Evain, à savoir si on ne va pas se retrouver avec 2 standards : .Net et Mono.
ATTENTION, je ne parle pas des spécifications de la VM ou du langage C#, mais des assembly fournies en standard avec le SDK.

Lire la suite

Winforms sous Linux

Après 4 ans de développement, la communauté Mono est enfin parvenu à l’implémentation complète des Winforms : http://tirania.org/blog/archive/2008/May-13.html

On peux se demander « oui, mais pourquoi faire? » et je ne trouve pas de réponse à la question. En effet, il arrive souvent qu’une application .Net possède du Legacy et donc des dépendances COM ou P/Invoke. Dans ce cas, on ne peut pas la migrer (pour tester si une migration est possible: http://www.mono-project.com/Moma)

Mais comme je suis exigent en terme d’interface, je n’aime pas avoir une application « alien » qui ne ressemble pas à mon environnement Linux (GTK/QT). Certes, il est prévu d’avoir un meilleur support du moteur de thème lors du prochain GSoC, donc wait and see.

Rappelons que les Winforms sont une sur-couche .Net de l’API WIN32. Cette dernière n’existant pas sous Linux et MacOS, j’en profite alors pour féliciter les équipes de Mono pour leur implémentation « from scratch ».

D’un autre coté, l’implémentation WPF chez Mono avance plutôt vite. D’ailleurs, la première release de Moonlight vient de sortir. Il n’y a pas de dépendance WIN32 dans ce cas, et je vois plus l’avenir des applications .Net dans ce sens. Mais l’approche WPF est d’avoir un thème propre à l’application, comme c’est le cas pour les sites Web, on obtient la même interface sous Linux et Windows (et MacOS). Mais finalement je trouve que ces interfaces ne s’intègrent à aucun des 3 environnements.

Lire la suite

A la conquête du Web 3.0

J’ai eu une discutions intéressante ce midi au sujet du buzz en ce moment: Adobe open-source Flash! Je vois ça comme un premier pas vers la conquête du Web 3.0. Une guerre déjà entamé entre Adobe, Microsoft et le monde libre.
Lire la suite

Suivre

Recevez les nouvelles publications par mail.