Le blog de L'ami S'ami

Bonjour à tous et bonne année 2008 avec beaucoup de retard. J'en profite aussi pour remercier ceux qui m'ont gentiment envoyé un mail ou passé un coup de fil.

L'année 2008 s'annonce très riche, pour DNG.org mais aussi pour DNG-Consulting, lequel a tendance à prendre en ce moment beaucoup de place sur les quelques slots réservés à mon activité de webmaster DNG.

Mais promis, parmi mes nouvelles résolutions, celle de blogguer plus, continuer à publier sur DNG ou ailleurs (j'en profite pour vous informer qu'un article sur le DDD sortira dans un prochain hors série du magazine Programmez), celle ne de pas vous faire regretter le prochain Symposium DNG (très prenant). Et celle enfin d'organiser un séminaire technique très particulier qui me tient à coeur et dont je livrerai quelques détails courant Février.

2008 sera une année très spéciale pour moi car c'est d'une certaine manière un retour aux sources. Contrairement aux années précédentes (très "évangélisantes"), mon activité sera focalisée à 80% sur du développement et la mise en pratique des nombreuses idées/bonnes pratiques formalisées plus ou moins dans ma tête depuis des années. Que ce soit sur la partie serveur (EJB3, SOA, WCF) ou cliente (GWT, Volta, Swing, etc..), je ferais partager tout au long de l'année ces bonnes pratiques, à commencer par le Symposium DNG qui sera un avant-goût de la conférence suivante.

Sinon, pour ne pas donner à ce billet un parfum d'auto-actualité pseudo nombriliste, je voulais rebondir sur la dernière annonce de Microsoft (relayée par Scott Guthrie) dévoilant très officiellement les manipulations à suivre pour profiter du code source du Framework .NET.

Ces manipulations marchent parfaitement sur mon poste, j'ai enfin pu lire le code source de la classe Control.cs du namespace System.Windows.Forms sans avoir l'impression de violer une quelconque licence (cf Reflector). En revanche, je trouve que cette ouverture n'est pas encore suffisante ou plutôt trop contraignante. Pour bénéficier de cet accès, le poste de développement doit :
- Posséder une connexion Internet ouverte en permanence
- être en session de Debug avec la pile d'exécution affichée dans une console sur la classe du Framework qu'on souhaite visualiser
- Télécharger un "patch" particulier pour VS.NET

Il faut avouer que pour quelqu'un qui cherche à comprendre du code source en passant d'une classe à l'autre, on fait plus simple. D'autant plus que la même opération sous Eclipse se résume à un "Attach Source Code" sur une archive (l'équivalent d'une DLL .NET) suivi d'un simple control+click ouvrant automatiquement le code source sur la méthode ou classe en question.

Du coup, j'ai essayé d'analyser la manière dont Visual Studio s'y prenait pour récupérer ce code source. Le tout en plaçant un proxy entre VS.NET 2008 et le "Web" dans une session Fiddler.

Les résultats de l'analyse Fiddler sont plutôt étonnants, ils nous indiquent que le serveur de source est ReferenceSource.microsoft.com et que les sources sont placés hiérarchiquement suivant une convention de nommage plutôt complexe. Autant dire qu'on est loin d'un serveur SVN, CVS ou TFS (Team Foundation Server). Autre aspect plutôt déroutant, lorsqu'on accède via un navigateur à ce repository, toute requête se solde par un status code 400, une page blanche en quelque sorte.

Microsoft a donc protégé ces sources pour que seul Visual Studio puisse y accéder avec une clé privée particulière (placée dans le cookie RSCCAuth). Lorsqu'on essaye la première fois de télécharger un fichier, une page dédiée à la licence s'affiche. Après acceptation, un cookie est généré et servira de clé d'accès.
Autant dire que pour une ouverture annoncée en fanfare, on aurait pu s'attendre à quelque chose de plus "Ouvert" justement ;-).

Bref, tout cela m'a donné une idée (et oui encore!). Reflector s'est fait une réputation mondiale sur la décompilation de code source. On pourrait imaginer un plugin VS.NET qui, sur l'appui de la touche F3 (Go To Definition) irait récupérer la clé Visual Studio générée par défaut pour ensuite enclencher un GET HTTP sur le serveur ReferenceSource. Ce plugin (pas très complexe à développer) serait une aubaine absolue pour nombre de développeurs et s'appuierait surtout sur la base d'origine de Microsoft.

D'ailleurs, peut-être que Microsoft lui même pourrait nous le fournir ?

A bon entendeur...

Mise à jour: bon j'avoue ne pas avoir pu résister à l'envie de proof of concepter l'AddIn en question. Ca marche plutôt bien et à priori sans exécuter les opérations listées sur le site de ScottGu.
Lancez le setupNetExplorer.msi, une entrée de menu apparaît dans Tools, une fois activé l'Add-In télécharge la classe Control.cs sur le site de Microsoft avec un cookie d'authentification qui semble fonctionner dans tous les cas. Voici le code source pour ceux qui souhaiteraient industrialiser le prototype, il n'y a plus qu'à enrichir la base de données des codes sources téléchargeables et cabler l'appui sur la touche F3. Avec le disclaimer d'usage sur les responsabilités de l'auteur hein ;-)