The World is mine

La plateforme .Net fournit un mécanisme pour gérer les paramétrages. Il en existe 2 types : ceux de l’application et ceux de l’utilisateur. Au début de l’existance, il y avait la bonne vielle méthode du fichier *.ini, mais aujourd’hui le XML et devenu LE standard pour écrire des données dans un fichier “lisible” et structuré.

Il existe un autre standard : les applications .Net possède un fichier “mon_application.exe.config” qui n’est autre qu’un XML contenant le paramétrage de l’appliation. Ce fichier est structuré en 2 grosses parties: l’entête avec la section “configSections” qui décrit les sections du XML et les “parser” qui vont lire ces dernières. Puis il y a les sections proprement dites.
Lisez la suite de cette entrée »

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.

Lisez la suite de cette entrée »

Deux mondes s’affrontent: Java et .Net. Chacun choisi son camp, ou choisi les deux… moi j’ai la double nationalité Mais quand les deux mondes doivent alors communiquer? Je fais l’interprète. Voila le topo:
J’ai une application .Net qui a besoin de manipuler des classes Java, et pour se faire je passe par C++/CLI: comment avoir un pied dans du .Net et un autre dans du natif C++.
Lisez la suite de cette entrée »

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.
Lisez la suite de cette entrée »

Rien de plus stressant que de passer une journée entière sur un bug. Surtout si on n’a aucune idée du problème (pas d’exceptions, ni d’erreurs dans les logs) et que les recherches sur Internet sont infructueuses.
Contexte : une application Web Asp.Net communique avec un service WCF.
Problème : au bout d’un certain nombre d’appels (invariant) l’application Web n’arrive plus à joindre le serveur (Timeout).

Lisez la suite de cette entrée »

On a parfois besoin de livrer une application .Net avec les fichiers de ressources, afin qu’un traducteur, voir même un intégrateur, puisse faire les traductions au dernier moment.

Si cette personne doit recompiler l’application pour voir le fruit de son travail, ce n’est pas très pratique voir impossible: allez lui expliquer que VisualStudio n’est pas nécessaire et qu’il est possible de créer des ressources avec ResGen.exe (et al.exe pour faire des assembly satellites). Très franchement, les traducteurs ne veulent pas de quelque chose d’aussi et vont vous fuir comme la peste si vous leur demander d’être des développeurs.

Lisez la suite de cette entrée »

Il existe de nombreux framework d'application web, tel que Spring, Struts, JavaServerFaces ou WebForms…
Mais qu'en est-il des "clients riches", cad, des applications graphiques faites en WinForms, GTK, etc…

Dans le monde Java, il y a Eclipse RCP, qui est pour moi sans conteste le meilleur framework d'application. Il y a aussi Spring RCP que je connais mal.

Dans le monde .Net, CAB est sans doute le plus connus, et pour cause c'est le framework proposé par M$, mais il en existe d'autre comme eXpressApp (de DevExpress).

On peut aussi se faire son propre framework… et je vais essayer de lister les avantages et inconvénients de coder soi même ou d'utiliser l'existant car, bien évidement, aucune solution n'est parfaite et la bonne solution est celle qui s'adapte le mieux au besoin…

Lisez la suite de cette entrée »

Echec total

Je voulais tester Cygnome en en faire mon shell par défaut sous windows…. je n’y arrive pas.

De même pour Xorg. La Warty d’Ubuntu est fournie avec XFree, mais je voulais tester les effets d’ombres et de transparences avec Xorg…. mais je dois m’armer de patience.

Bref, je passe à autre chose. Mes projets sont :

• continuer mes recherches sur lwjgl
• re-coder ma petite appli .Net à la WhereIsIt avec sérialisation XML (SOAP ?)
• re-coder mon projet de licence en .Net avec Maverick.

En ce qui concerne le serveur ASP.Net, je me suis amusé avec Apache2 couplé à Cassini (ou le serveur XPS de Mono) grâce à mod_proxyredirect ^^

Après avoir passé quelque minutes sur un Tuto, voila ma première appli Mono avec GTK# et le composant Gecko (Mozilla) à l’aide de MonoDeveloppement et GLade (tjs sous nux ) :

De retour sous nux… car les ralentissements sous win me soulent…

Puis je ne sais pour quel raison, je teste la ligne de commande suivante :

>mono Helloworld.exe

Et hop! Le programme ce lance ! Pouvoir exécuter des applis compilées avec le framework mono ça devient de plus en plus sympa