Monthly Archives: juillet 2011

Erreur commune du Just-In-Time Debugger

À chaque nouvelle installation d’un environnement de développement pour SharePoint 2010, j’ai quelques fois par jour un message d’erreur lancé par Visual Studio 2010. Ce message d’erreur me demande de déboguer le processus OWSTIMER.exe, puisque celui-ci a lancé l’erreur “System.Secyrity.Cryptography.CryptographicException”.

Le problème est causé par une clé d’encryption mal gérée lors du recyclage du processus OWSTIMER.exe.

Afin de régler la situation, il suffit de supprimer 2 (ou 4 sur un système x64) clés de registre qui indiquent à Visual Studio 2010 de déboguer les exceptions non géréees par les systèmes .NET.

Les clés à supprimer sont les suivantes :

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger

Pour un système x64, les clés supplémentaires à supprimer sont les suivantes :

  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger

Pour télécharger les fichiers de gestion du registre, utilisez les liens suivants :

Le singleton générique

Dans la série des articles sur le singleton, je trouvais primordial de discuter de généricité.

Lorsqu’un programme, une application, un module, etc., est développé de façon professionnelle et durable, celui-ci se doit d’avoir une généricité optimale. Celle-ci aura comme résultat de réduire le nombre de ligne de code, de simplifier l’implémentation d’une fonctionnalité et permettra de réutiliser certains concepts dans un autre but, sans avoir à modifier quoi que ce soit. Le singleton ne fait pas exception et peut être gérer au maximum de la généricité.

Prenons un cas concret, le cas d’une application qui doit utiliser de la journalisation (logging). Trois types de journalisations sont disponibles : Journal d’événement, Fichier .txt et Base de données. Chacun de ces types de journalisation héritent de certains comportements du parent, soit l’objet Journalisation.

Notre hiérarchie est donc la suivante :

Hiérarchie

Sachant que nous ne voulons qu’une seule instance de chacun des types de journalisation, il serait intéressant d’implémenter le singleton dans chacune des classe concrète de journalisation. Nous aurions donc le schéma suivant :

Singleton

Cette implémentation est bien, mais peut être encore améliorée.  Pourquoi ? L’action d’instancier un singleton est toujours la même.  Il serait donc intéressant de généraliser le comportement dans la classe parent en lui ajoutant l’instanciation unique d’un type de journalisation.  Le schéma obtenu serait donc :

Singleton générique

Maintenant toute cette belle réalisation théorique effectuée, il est temps de le coder… et de s’arracher les cheveux de la tête parce qu’on se rend compte bien vite que la création d’objet concret dans un objet abstrait est beaucoup plus complexe qu’on puisse le penser.  En détails, voici le problème : dans les technologies .NET, une instanciation doit être explicite, c’est-à-dire qu’on ne peux faire que des nouvelles instances de types connus, ou de types génériques ayant le marqueur d’instanciation.  On ne peut donc pas faire une instanciation d’un type enfant générique sans passer par l’utilisation de la réflexion.  Dans le cas qui nous intéresse, la classe Journalisation ne peut pas instancier aucun de ses enfants, puisqu’elle ne les connait pas du tout.

Ici-bas, on trouve la classe parent, qui gère l’instanciation du singleton :

public abstract class Journalisation<T> : where T : Journalisation
{
    #region Membres prives
    /// <summary>
    /// Singleton private member
    /// </summary>
    private T singleton;
    #endregion

    #region Singleton
    /// <summary>
    /// Implementation d'un singleton generique de journalisation
    /// </summary>
    public static T Instance
    {
        get
        {
            if (singleton == null)
            {
                singleton = (T)Activator.CreateInstance(typeof(T));
            }

            return singleton;
        }
    }
    #endregion

    #region Constructeurs
    /// <summary>
    /// Constructeur prive
    /// </summary>
    private Journalisation() { }
    #endregion
}

Et on trouve la classe enfant, qui se fait instanciée par le comportement hérité de son parent :

public class FichierTxt : Journalisation<FichierTxt>
{
    #region Constructeurs
    /// <summary>
    /// Constructeur prive
    /// </summary>
    private FichierTxt() : base() { }
    #endregion
}

De cette façon, tous les enfants pourront être des enfants de type singleton, sans avoir à gérer le comportement d’instanciation unique d’eux-même.

La généricité de cette solution permet d’isoler les responsabilités et assure une continuité et une facilité dans la maintenance d’une base de code.

Dans le prochain article, on améliorera le concept présent lors de son utilisation dans le contexte d’une requête HTTP.

Revisiter le singleton

Le singleton. Le patron de conception utilisé, surutilisé et surtout mal utilisé par les développeurs. Bien que l’idée derrière celui-ci semble être géniale et convenir à toutes les situations, il est important de bien le comprendre et ne pas tomber dans le piège de l’utilisation fautive de ce patron.

Tout d’abord, pour les développeurs moins habitués avec cet paradigme de programmation, voici ce qu’est, selon Wikipédia, un singleton dans un développement applicatif.

En génie logiciel, le singleton est un patron de conception (design pattern) dont l’objet est de restreindre l’instanciation d’une classe à un seul objet (ou bien à quelques objets seulement). Il est utilisé lorsque l’on a besoin d’exactement un objet pour coordonner des opérations dans un système. Le modèle est parfois utilisé pour son efficacité, lorsque le système est plus rapide ou occupe moins de mémoire avec peu d’objets qu’avec beaucoup d’objets similaires.

Singleton

Dans ma réalité actuelle, le singleton comporte un grand nombre d’avantages, sûrement encore plus d’inconvénients. Lorsqu’on joue avec les technologies Microsoft et .NET, certaines fonctionnalités ne nous permettent pas de jouer avec un singleton comme on le voudrait. Des situations bien précises m’ont pousser à repenser et améliorer le singleton dans le contexte de la programmation au sein de la plateforme SharePoint (et ASP.NET, en général).

Dans mes récentes recherches, les deux aspects suivants ont été revisité afin de redorer l’image du singleton :

  • Support générique de l’héritage des comportements de singleton
  • Gestion du singleton aux travers d’une requête HTTP

Dans les prochains billets, ces deux aspects seront mis de l’avant et permettront de comprendre le problème, d’analyser le cheminement vers la solution, et de voir une ébauche de la solution proposée. Vous pourrez revenir plus tard sur ce billet afin d’avoir une mise à jour vers les liens des billets à ce sujet.