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.

Comme je vous l’ai indiqué il y a 2 semaines, j’ai participé ce mois-ci à mon 3ème MVP Summit qui s’est déroulé comme chaque année à Seattle et à Redmond directement sur le Campus Microsoft.

Je n’y étais pas seul puisque cette année j’étais accompagné de deux collègues de Bewise : Jean Pierre Riehl [MVP SQL Server] et Frédéric Colin [MVP Connected Systems].

Le summit est l’occasion de rencontrer les équipes produits de Microsoft Corp. et ceci pour toutes les technologies/produits de l’éditeur. C’est ainsi que près de 700 sessions ont été organisés afin d’accueillir 1500 MVPs qui ont fait le déplacement pour l’occasion.

Le gros point fort de cet évènement réservé aux MVPs par rapport aux évènements plus “traditionnels” comme les Tech’Ed ou la PDC est la qualité des rencontres et discussions que l’on est susceptible d’avoir. Il est en effet possible de rencontrer ses pairs, afin d’échanger, de confronter ses idées/opinions à propos des différentes technos MS. On peut ainsi partager différents retours d’expériences sur des projets très variés

Le MVP Summit c’est également l’occasion d’avoir un contact direct avec les équipes de développement de Microsoft Corp. et avoir ainsi la possibilité de discuter directement avec les personnes qui créé, concoivent, et développent  les technos que nous utilisons tous les jours. Après avoir été nommé MVP ASP.net pendant 3 ans, j’ai ainsi découvert l’équipe de développement du langage C# puisque j’ai été nommé sur cette spécialité l’année dernière. Le moins que l’on puisse dire c’est que lorsque Microsoft affirme que les MVPs sont des contacts privilégiés qui ont un fort impact sur les différents développements en cours, l’éditeur ne ment pas et l’organisation du summit qui a été faite par la team C# répond exactement à cela. Une grande partie des sessions auxquelles j’ai participé étaient en effet des sessions de discussions et de feedbacks avec les responsables des différentes équipes (langage, intégration à l’ide, etc.) Nous avons ainsi pu discuter sans langue de bois afin d’indiquer les axes d’amélioration qui pouvait être pris pour les prochaines versions du langage et de Visual Studio. En plus de cette occasion unique de pouvoir échanger avec les personnes qui “font” les technos, nous avons pu poser quelques questions à plusieurs Technical Fellows un titre décernée par Microsoft aux Microsoftees qui ont un fort impact sur l’industrie informatique. C’est ainsi qu’Handers Heljsberg,  Mohsen Agsen, Patrick Dussud et Brian Harry ont joué le jeu des questions réponses sous la direction de Soma Somasegar, Directeur de la division développement. 

Bien entendu, le summit c’est également l’opportunité de voir en avant-première le futur de différentes technologies que nous verrons dans les prochains mois/années mais sur ce point je ne pourrais rien dire NDA oblige…

En savoir plus :
Le compte rendu de Fabrice Romelard [MVP Sharepoint]
Le compte rendu de Jean Pierre Riehl [MVP SQL Server]
Le compte rendu de Sebastien Picamelot [MVP Sharepoint]

Comme chaque année, me voilà à Seattle pour une semaine afin de participer au Microsoft MVP Summit 2009. Le summit est l'occasion de retrouver ses pairs afin de partager et confronter ses opinions et idées sur les différentes technologies. Il s'agit également d'une occasion unique de rencontrer les équipes de Microsoft Corp afin de directement remonter différents feedbacks sur les produits et avoir un aperçu des prochaines versions qui arriveront prochainement.

Malheureusement l'événement est sous NDA donc je ne pourrais rien révéler de bien important durant la semaine qui arrive. La semaine devrait donc être assez calme sur le blog...

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

Disposer d'une machine virtuelle et d'une compilation en deux phases permet de bénéficier d'un support du 64 bits quasi-automatique. Si l'on compile une assembly en Any Cpu, celle-ci sera compilée en JIT en 32 bits si elle est chargée dans un process 32 bits ou en 64 bits dans le cas d'un chargement dans un process 64 bits. De plus si une assembly a des dépendances vers des assemblys 32 bits ou vers des DLL natives 32 bits,  elle se retrouvera automatiquement compilée en 32 bits même si chargée dans un environnement 64 bits.

Il faut cependant noter que cette analyse de dépendances ne concerne que les dépendances statiques et en aucun cas les dépendances dynamiques (introduites via du code).

J'ai récemment rencontré le problème à propos de l'utilisation d'un filtre DirectShow. Le filtre est instancié via un Activator.CreateInstance afin d'être manipulé et insérer au sein d'un graphe de cette manière :

    /// <summary>
    /// Wrapper of the HttpDestinationFilter
    /// </summary>
    public class HttpDestinationFilter
    {
        private static readonly Guid CLSID_HttpDestination = new Guid("E6788379-AAA3-4516-86EC-158B7A49EA74");

        public static IBaseFilter CreateInstance()
        {
            return (IBaseFilter) Activator.CreateInstance(Type.GetTypeFromCLSID(CLSID_HttpDestination, true));
        }
    }

Seul problème, lors de l'exécution de ce code sur une plate-forme 64 bits, l'instanciation peut échouer si le composant en question est en 32 bits et si l'assembly est compilée en Any Cpu.

Etant sur un Windows 64 bits, la base de registres est en grande partie divisée en deux versions, une copie pour les applications 32 bits et une autre copie pour les application 64 bits. Il est ainsi (entre autres raisons) impossible d'utiliser des composants COM 32 bits depuis une application 64 bits car le composant se retrouve introuvable du fait de la redirection. La correction du problème est simple : trouver une version 64 bits du composant en question ou alors définir manuellement la target de compilation afin d'indiquer un compilation en 32 bits.

Microsoft propose une version Checked Build de ses OS. Si vous êtes abonnés MSDN vous avez la possibilité de télécharger la version "normale" ainsi que cette fameuse version alternative :

La version Checked Build proposée par Microsoft est une version de Debug. Elle est définie selon 4 options qui sont activées pour cette version mais qui ne le sont pas pour d'autres types de build :

• Les optimisations de compilation [O]
• Les traces de debug [D]
• Les assertions [A]
• Les contrôles d'intégrités [S]

Concernant les build dites "checked", toutes ces options sont activées. Pour les autres types de builds vous pouvez vous référer au tableau suivant :

En savoir plus :
Checked and Free Build Differences
WHERE DO "CHECKED" AND "FREE" COME FROM?

Durant la PDC08, Microsoft a annoncé que la prochaine version de Visual Studio sera basé sur WPF afin de fournir une interface graphique plus riche. Malgré cette annonce nous n'avions jusqu'à présent rien vu de bien alléchant concernant cette fameuse intégration.

C'est à présent chose fait grâce à Jason Zander qui propose sur son blog quelques screenshots de VS 2010 qui est toujours en cours de développement. Bien que non définitifs, ils permettent d'avoir une idée de la direction prise par Microsoft en ce qui concerne le look & feel de l'IDE.

En savoir plus :
http://blogs.msdn.com/jasonz/archive/2009/02/20/a-new-look-for-visual-studio-2010.aspx

Telle est la pertinente conclusion de Scott Hanselman après l'analyse du fonctionnement des navigateurs Chrome et Internet Explorer 8. Ces deux browsers utilisent en effet le même modèle d'isolation inter-onglets. Chaque onglet tournant dans un process différent, la stabilité de ces applications s'en retrouve améliorée grâce à ce niveau d'isolation bien supérieur aux AppDomains que l'on connait dans le monde .net.

Cette utilisation peut être révelée via l'utilisation de Process Explorer ou plus simplement directement via la commande about:memory dans Chrome. Cette commande affiche la consommation mémoire du navigateur, consommation définie via les différents process utilisés :

Fait intéressant, les process créés et gérés par ces navigateurs sont des process d'un type particulier appelé jobs. Ces jobs peuvent être gérés de manière globale, et des quotas d'allocation de ressources peuvent leur être atrribués.

Pour en savoir plus, rendez-vous sur le post d''Hanselman.

Dans le genre truc à la con que j'oublie à chaque fois, pour parcourir la callstack durant l'exécution d'un programme - afin de par exemple connaitre la méthode d'appel - il faut utiliser la classe StackTrace présente dans le namespace System.Diagnostics afin de récupérer les différentes StackFrame représentant les différentes frames de votre pile d'appel. La première (indice 0) étant la méthode actuelle et la seconde représentant la méthode d'appel précédente. Vous pouvez ainsi remonter jusqu'où bon vous semble.

Exemple rapide de code :

             static void Main(string[] args)
             {
                    Toto();
             }

             static void Toto()
             {
                    StackTrace trace = new StackTrace();
                    StackFrame frame = trace.GetFrame(1);

                    MethodBase method = frame.GetMethod();

                    Console.WriteLine(frame.GetMethod().Name);
             }

Si vous êtes éditeur de logiciels et que vous souhaitez avoir des informations détaillées lorsque vos applications rencontres des problèmes inattendus sachez que vous pouvez récupérer les rapports envoyés par les utilisateurs lorsqu'ils rencontrent ce message d'erreur :

Si l'OS propose aux utilisateurs d'envoyer des rapports d'erreurs pour toutes les applications et non pas uniquement pour celle de Microsoft, ce n'est pas à des fins d'espionnage mais pour permettre aux éditeurs d'améliorer la qualité de leurs logiciels. Il est en effet possible d'accéder gratuitement à ces rapports d'erreurs via le site Windows Quality Online Services. Il suffit pour cela de s'inscrire et de s'identifier de manière formelle en tant qu'éditeur de logiciels via un certificat Verisign.

En savoir plus :
Windows Quality Online Services