Débutant une formation WPF la semaine dernière chez un client, je me suis retrouvé sur un problème intéressant : lors de la création de projets WPF, le code généré par Visual Studio ne compilait pas. Inutile de vous dire qu’il s’agit du genre d’incidents qui jette un rapide discrédit sur la technologie ce qui n’est évident à gérer en début de formation…

Le problème est lié à l’utilisation du langage VB et de la directive Option Strict. Si vous êtes un développeur VB sérieux et rigoureux vous avez très probablement activé l’option strict afin d’éviter d’autoriser le compilateur à ne pas signaler les opérations de cast plutôt hazardeuses. Seul problème, le code généré par les templates de projet de WPF n’est pas compatible avec cette vérification du compilateur si vous utilisez Visual Studio 2008 RTM :

En effet si vous éditez le fichier MyWpfExtensions.vb présent au sein de votre projet vous trouverez la ligne de code fautive :

Friend ReadOnly Property Application() As Application
    Get
        Return Global.System.Windows.Application.Current
    End Get
End Property

Il est nécessaire de modifier le code du getter afin d’ajouter un cast explicite afin que le code compile correctement :

Friend ReadOnly Property Application() As Application
      Get
          Return CType(Global.System.Windows.Application.Current, Application)
      End Get
End Property

La solution pour résoudre ce problème est simple : il vous faut installer le Service Pack 1 de Visual Studio 2008.

Autre solution si avez un besoin très urgent du correctif, vous pouvez directement télécharger les templates mis à jour sur cet article de la KB de Microsoft.

Les regions sont incontestablement la fonctionnalité que je déteste et qui m’insupporte le plus dans Visual Studio. En voir dans du code, me fait enrager, grogner, avoir des boutons dans 98% des cas où je les rencontre.

Les regions permettent de définir différentes zones dans du code, zones qui peuvent être nommées et qui peuvent être rétractables. Le principal reproche que je trouve aux régions réside tout simplement dans le rôle même de cette fonction : MASQUER LE CODE.

Car après tout, les régions ont été créés dans un seul et unique but : masquer du code que le développeur ne doit pas voir ou modifier :

Cela avait donc une utilité avant que les classes partielles existent afin de masquer du code qui est généré et qui donc par définition ne doit pas être modifié (sous peine de voir les modifications supprimées lors de la prochaine génération de code) en le plaçant dans un autre fichier.

Vous l’avez compris, je ne comprends pas quel est l’intérêt de masquer du code. Lorsque je consulte des fichiers sources je souhaite avoir la meilleure lisibilité possible afin de comprendre le fonctionnement du code que je suis en train de lire. Le voir masqué m’oblige à utiliser mes dons de contorsionniste des doigts afin de déplier ces fameuses régions qui, pour certains développeurs, servent à “ranger” ou “classer” du code source de “manière plus propre”.  Dans la très majorité des cas, si vous avez besoin de “ranger” votre code source présent dans une classe en plus zone, c’est que votre classe fait beaucoup trop de choses que ce qu’elle devrait faire. Repenser la séparation des responsabilités permet de résoudre le problème. Si vous regroupez plusieurs méthodes et/ou propriétés dans une région particulière, il y a une forte probabilité que cet ensemble devrait se trouver dans une autre classe. Et si vous groupez des lignes de code d’une même méthode en plusieurs régions, cela signifie que votre méthode à trop de responsabilité et qu’il serait bon de la splitter en différentes méthodes distinctes.

Le seul avantage que je vois donc aux régions, et qu’il permet de voir du premier coup d’œil quel est le code qu’il est urgent de factoriser.

Microsoft vient de l'annoncer via une mise à jour de la page dédiée au support de Visual Basic 6, le runtime de VB6 sera présent sur Windows 7. Windows 7 sera probablement ainsi le dernier OS a support ce runtime, l'éditeur n'ayant pas prévu de l'inclure dans les versions ultérieures.

Ceci est donc une bonne nouvelle pour la compatibilité de ces applications, mais bon, il va falloir penser à migrer vers .net un jour quand même :)

En savoir plus :
Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7

Le bug décrit dans ce précédent post et son impact dans l'utilisation de CodeDom vient d'être fermé sur Connect. La solution adoptée par Microsoft est de ne pas modifier le comportement du compilateur mais de mettre à jour la documentation. Ils ont donc choisi la moins mauvaise des solutions possibles, et je suppose qu'ils n'ont pas souhaité le corriger car ce bug n'est pas critique et des workarounds  sont très simple à mettre en oeuvre. Une mise à jour de la documentation est donc appropriée.

En attendant cette mise à jour, pensez-donc bien à rajouter une extension .dll ou .exe aux paths que vous définissez via la propriété OutputAssembly si vous souhaitez compiler du code VB via CodeDom.