J'ai eu le plaisir de participer à un CodeCamp en Ardèche organisé par Jb Evain afin de débuter le développement d'un décompilateur .net Open Source basé sur Mono.Cecil.

Ces 4 jours furent l'occasion de revoir quelques amis tels que Jb, Vincent et mathieu, mais aussi de faire de nouvelles connaissances puisque Robert Pickering (Auteur de l'ouvrage Foundations of F#), Romain Verdier et Sebastien Lebreton (développeur de Reflexil, un addin Reflector permettant de modifier les assemblys .net) étaient également présents.

J'ai débuté ma modeste contribution en écrivant un addin pour NUnit destiné à permettre de tester le résultat des décompilations en mode Debug ET en mode Release. L'objectif étant d'écrire un test une fois pour toute et de générer en correspondance un test pour le mode debug et un test pour le mode release.

Pour cela, nous avons décidé de partir de fichiers .cs ou .vb inclus dans les projets de tests, de les compiler "dynamiquement" en debug et en release grâce à CodeDom, de les décompiler via Cecil.Decompiler et de tester le résultat de cette décompilation avec le contenu de fichiers textes contenant le résultat attendu. Cela nous a permis de définir un ensemble de TestCases permettant de tester la décompilation des structures communes ou propres à chaque langage.

Rien de bien compliqué donc mais cela m'a permis de découvrir les mécanismes d'extensibilité de NUnit et ainsi de regretter le fait qu'il n'y ait que le client NUnit qui ne supporte les AddIns NUnit, cela peut paraître évident, mais j'aurais pensé que R# ou TestDriven.net supportait ce type d'addin, car le fait de développer un addin NUnit impose donc d'utiliser NUnit comme test runner... Ce qui est quand même assez dommage...

Le développement de cette couche de test m'a également permis de découvrir un bug dans le compilateur de Visual Basic qui m'a fait perdre un peu de temps. Le compilateur de VB gère en effet de la paramètre /out de manière incorrecte. Celui-ci se comporte de manière différente que celui de C# mais également différemment que ce qu'indique la documentation du compilo VB !

En fait un appel de la commande suivante :

c:\Program Files\Microsoft Visual Studio 9.0\VC>"C:\Windows\Microsoft.NET\Framew
ork\v2.0.50727\vbc.exe" /t:library /utf8output /out:"C:\Users\plamarche\AppData\
Local\Temp\tmpEEC8.tmp" /debug- "C:\Users\plamarche\Documents\Visual Studio 200
8\Projects\ClassLibrary6\ClassLibrary6\Class1.vb"

Ne génère pas un fichier tmpEEC8.tmp comme on pourrait s'y attendre (et comme le compilateur C# le fait) mais génère un fichier tmpEEC8.tmp.dll à la place. Le compilateur concatène l'extension .dll au chemin spécifié dans le paramètre /out.

Ce problème peut sembler de premier abord anodin, mais il n'a pas été évident de le diagnostiquer puisque j'ai rencontré le problème non pas en appelant le compilateur VB directement mais en utilisant CodeDom. Utilisant CodeDom afin de compiler du code C# ou VB en debug ou en release, j'ai défini la propriété OutputAssembly afin de définir le chemin de l'assembly, résultat de la compilation, grâce à un appel à Path.GetTempFileName(). Le problème est que la création d'assembly via CodeDom diffère en fonction du langage compilé (à cause de la différence des comportement des compilateurs utilisés), ce qui est n'est pas du tout normal ! Alors que lors de la compilation de code C# donne bien le fichier attendu (un .tmp) la compilation de code VB donne un nom de fichier différent (.tmp.dll) (d'ailleurs au passage, je pensais au début que le compilateur ne compilait pas du tout puisque le .tmp est bien présent mais reste vide laissant penser que le compilo n'a rien fait du tout, mais en réalité c'est l'appel à GetTempFileName qui créé le fichier vide afin de réserver le nom de fichier).

De plus, la documentation du compilateur VB n'indique pas tout cela puisque il est indiqué que :
"The compiler expects to find the output file following the /out option.
Specify the full name and extension of the file to create. If you do not, the .exe file takes its name from the source-code file containing the Sub Main procedure, and the .dll file takes its name from the first source-code file" http://msdn.microsoft.com/en-us/library/std9609e.aspx

Vous pouvez consulter la soumission de bug et voter pour celui-ci en consultant sa fiche sur Connect : http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=387915. On verra bien comment Microsoft le traitera sachant qu'il y a 3 options possibles :

• La meilleure (si cela n'a pas d'impact au niveau de la compatibilité) : corriger le compilateur
• La moins mauvaise : corriger la documentation
• la mauvaise : ne rien faire du tout :)

Pas rancunier pour un sou, j'ai ensuite rejoint l'ami Vincent pour débuter le décompilateur VB. Cela ne fut pas sans problème puisque l'on s'est vite rendu compte que le compilateur VB générait des structures de code IL ou des instructions IL très particulières, pas du tout utilisés par le compilateur C#, et donc pas encore gérées par les couches basses du décompilateur. Ce fut pour moi l'occasion de redécouvrir le VB et ainsi me rappeler des différentes particularités de ce langage, comme par exemple dans le domaine de la gestion d'exceptions avec la clause When qui permet de filtrer plus finement les exceptions, ou encore le fameux On Error Resume Next qui au niveau de la compilation génère quelques surprises...

A noter qu'une partie du travail réalisé est à présent disponible sur le svn de Mono : http://anonsvn.mono-project.com/source/trunk/cecil/decompiler

En savoir plus sur le CodeCamp :
Le post de Jb : http://evain.net/blog/articles/2008/12/16/decompiler-codecamp et http://evain.net/blog/articles/2008/12/15/cecil-decompiler
Le post de Robert : http://strangelights.com/blog/archive/2008/12/21/1631.aspx
Le post de Romain : http://codingly.com/2008/12/16/cecildecompiler-un-decompilateur-net-opensource/
Le post de Vincent : http://evilznet.com/post/Evilznet-apres-un-CodeCamp.aspx

Si vous avez lancé depuis hier la CTP de Visual Studio 2010 proposée lors de la PDC vous avez rencontré un sympathique message où MS vous informe qu'il faudra repasser plus tard pour continuer de travailler sur la future version de Visual Studio car l'image livrée il y a 2 mois périme le 1er Janvier 2009 !

En attendant que Microsoft veuille bien nous proposer de, de nouveau, télécharger une nouvelle version d'une VPC qui ne pèse que 8Go, la solution la plus simple est de ne pas sauvegarder votre VPC dans l'état actuel et de désynchroniser les horloges de la VPC et celle de votre machine hôte comme décrit sur ce post :
http://blogs.msdn.com/virtual_pc_guy/archive/2007/11/28/disabling-time-synchronization-under-virtual-pc-2007.aspx

Pour plus d'infos :
FAQ VS 2010 : https://connect.microsoft.com/VisualStudio/content/content.aspx?ContentID=10046
Post sur l'activation de Windows/Office, etc.
http://blogs.msdn.com/briankel/archive/2008/10/27/visual-studio-2010-ctp-vpc-dealing-with-activation-messages.aspx

Fini les screenshots de code source posté sur ce blog, je viens d'installer le projet SyntaxHighlighter disponible sur Google code.

Ce projet permet de mettre en forme de manière correcte le code source dans les posts de blog :

Pour installer ce projet sur DasBlog cela est assez simple. Rendez-vous dans le dossier contenant le thème que vous utilisez et modifiez le fichier homeTemplate.blogtemplate afin de rajouter les éléments suivants dans le header :

<script language="javascript" src="http://patricelamarche.net/scripts/shCore.js"></script>
<script language="javascript" src="http://patricelamarche.net/scripts/shBrushCSharp.js"></script>
<script language="javascript" src="http://patricelamarche.net/scripts/shBrushXml.js"></script>

Puis les lignes suivantes avant la fermeture de la balise <body/> :

<script language="javascript">
dp.SyntaxHighlighter.ClipboardSwf = 'http://patricelamarche.net/scripts/clipboard.swf';
dp.SyntaxHighlighter.HighlightAll('code');
</script>

Il ne reste plus qu'à copier les fichiers nécessaires présents dans le .rar sur le site du projet, là où vous les avez référencé et c'est terminé !

Point interessant pour tous les amateurs de Windows Live Writer (dont je fais parti), vous avez la possibilité d'utiliser un plugin disponible sur Codeplex : http://www.codeplex.com/wlwSyntaxHighlighter afin d'avoir une intégration fonctionnelle.

Après une petite customisation vous pouvez arriver à ce résultat là (oui je milite pour les fonds noir dans Visual Studio... A chacun ses combats :) 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication141
{
    class Program
    {
        static void Main(string[] args)
        {
        }
    }
}

[Update] Bon ok, la couleur des attributs XML ça pique un peu les yeux, mais bon pour le langage C# cela devrait faire l'affaire...

[Update2] Bon j'ai viré la mise en forme XML en attendant que j'ajuste le tir, histoire de ne plus avoir de commentaires désobligeants ;)

Si vous devez effectuer un binding qui dépend de plusieurs valeurs tout en étant capable d’être notifié dès qu’une modification a été faite sur une des deux valeurs, il est inutile de faire du bricolage pour arriver à une solution farfelue, il existe en WPF une solution toute prête qui permet de répondre à ce genre de problématiques : le MultiBinding.

Exemple simple  :

Une classe Personne :

Puis au niveau de l’interface :

Il faut donc ensuite créer un Converter afin d’indiquer la valeur à retourner en fonction des différentes propriétés bindées. Pour cela il ne faut pas créer un converter "classique" mais une classe qui implémente l'interface IMultiValueConverter qui prend en paramètre un tableau d’objets correspondant aux différents valeurs définies dans le multibinding (dans l’ordre de définition)

Résultat :

That’s All !

Tout est dans le titre, l'édition Data Dude de Team System 2008 est à présent disponible en RTM !

Pour toutes les infos sur les nouveautés apportées par cette rtm, vous pouvez vous rendre sur ce post : http://blogs.msdn.com/gertd/archive/2008/11/25/visual-studio-team-system-2008-database-edition-gdr-rtm.aspx

Cela se passe par ici : http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&DisplayLang=en

Lors de la PDC plusieurs démonstrations ont été faites à propos des nouvelles fonctionnalités dynamiques apportées à C# 4. Pour créer une classe dont le comportement peut s'apparenter aux types manipulés par les langages dynamiques, Microsoft a ajouté une interface IDynamicObject à implémenter afin de pouvoir appeler des propriétés, méthodes, champs non présents lors de la compilation. Lors de ces démonstrations, on a pu voir les différents Microsoftees utiliser une classe de base DynamicObject afin de bénéficier d'une implémentation par défaut. Cette classe DynamicObject n'est malheureusement pas disponible au sein du framework .net 4.0 tel que livré par Microsoft au sein de la CTP de Septembre.

Néammoins,  une bonne âme a bien voulu livrer les sources de cette classe afin d'être capable d'écrire du code se rapprochant des démos effectuées lors de la PDC : http://hagenlocher.org/software/DynamicObject.cs.txt

Source:
http://blogs.msdn.com/curth/archive/2008/11/07/dynamicobject.aspx

En C# nous avons la possibilité de rajouter une virgule à la fin de la liste des valeurs d’une enum.

Exemple :

La virgule après Buffering est accepté et le code compile sans aucun soucis.

La question qu’il est donc légitime de se poser est de savoir pouquoi le compilateur C# si rigoureux habituellement est-il autant laxiste dans le cas donné ?

Encore une fois, il s’agit d’une raison historique qui tire son origine du langage C++.

Le C++ permet en effet l’écriture de ce genre de code pour 3 raisons différentes :

· Faciliter la génération de code (pas besoin de supprimer le séparateur en fin de boucle)

· Minimiser les changements lors d’ajout de valeur (une valeur ajouté correspond à une ligne modifiée et non deux ce qui facilite la lecture des changesets)

· Permettre de définir des enums « bornées » où la dernière valeur correspond à la dernière valeur (dans le cas où votre enum a une valeur de départ et une valeur de fin). Si vous mettez une virgule après le dernier élément vous indiquez ainsi que ce dernier élément n’est pas « sémantiquement » le dernier.

Cf révision 59 des specs du C++ : http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#518

A noter que vous avez la même possibilité pour l’initialisation de tableaux ou pour l’initialisation d’objets introduite par C#3.

Le système d'exploitation Open Source et managé développé par Microsoft est à présent disponible sur Codeplex en Version 2.0.

Vous pouvez donc dès à présent télécharger les sources de cet OS afin de l'étudier ou afin de contribuer à ce projet.

A noter qu'une image ISO bootable est également disponible pour démarrer rapidement.

En savoir plus :
http://www.codeplex.com/singularity/Release/ProjectReleases.aspx?ReleaseId=19428

Lorsque Microsoft a annoncé pour la première fois que Silverlight allait supporter les vidéos HD, j'étais assez susceptique du fait de la bande passante nécessaire pour arriver à afficher des vidéos d'une telle qualité. Et bien je dois bien dire que je suis à présent totalement convaincu grâce au site de démonstration http://www.smoothhd.com qui permet de bénéficier des dernières fonctionnalités de IIS 7 en matière de streaming et des capacités de Silverlight en matière de lecture de vidéo haute qualité.

Le résultat est tout simplement bluffant : aucun temps de chargement, adaptation de la qualité de la vidéo en fonction des limitations en bande passante du client, etc. Le résultat final dépasse de loin ce que j'aurais pu imaginé. Un seul lien pour le découvrir par vous-même : http://www.smoothhd.com.

Un des reproches qui est le plus souvent fait au Visual Basic est les opérateurs Or et And évaluent dans tous les cas les deux opérandes contrairement à d’autres langages comme le C#. (Il faut utiliser OrElse ou AndAlso pour éviter ce comportement).

La raison de comportement qui peut sembler bizarre est en réalité tout à fait logique quand on sait que les opérateurs Or et And en VB ne sont pas des opérateurs logiques mais des opérateurs binaires. Ce qui veut donc dire que ces opérateurs effectuent une comparaison bit à bit de chaque opérande afin de produire un résultat. C’est ainsi que 3 Or 4 = 7 et 2 And 4 = 0. Ainsi le Or et le And ne sont pas les équivalents des opérateurs || et && mais plutôt des opérateurs | et &.

Concernant les valeurs booléennes, True étant égal à -1 en VB, les opérateurs Or et And agissent comme s’il s’agissaient d’opérateurs logiques (à l’exception près que les deux opérandes sont évalués puisqu’il s’agit d’une opération binaire). Pour ceux qui trouvent bizarre qu’en VB le True est égal à -1 voici une petite explication :

« La constante booléenne True a la valeur numérique -1^[4]. Ceci est dû au fait que le type booléen est codé comme un entier de 16 bits signé. Dans cette représentation, -1 est codé comme une suite de 16 « 1 binaires » (la valeur booléenne True), et que 0 est codé comme 16 « 0 binaires » (la valeur booléenne False) ; lorsque on effectue l’opération Non Logique sur un entier signé de 16 bits valant 0, on obtient -1. En d’autre termes, True = Not False. Cette caractéristique intrinsèque devient particulièrement utile lorsque l’on effectue des opérations logiques bit à bit sur un entier, telles qu’And, Or, Xor et Not. Cette définition est également globalement cohérente avec les implémentations de BASIC depuis Microsoft Basic, au début des années 1970. C’est également en adéquation avec les caractéristiques des microprocesseurs de cette période. » http://fr.wikipedia.org/wiki/Visual_Basic#Caract.C3.A9ristiques_de_Visual_Basic

Cette astuce a donc  permis d’éviter d’implémenter les deux types opérateurs (binaires et logiques) comme c’est le cas dans d’autres langages (C#, C, C++, etc.)

Pour en savoir plus sur cette différence :
http://www.panopticoncentral.net/archive/2003/08/18/179.aspx