Impossible de lancer le debugger de Visual Studio 2005

Le message d’erreur qui apparaît lorsque l’on lance un programme depuis Visual Studio 2005 (ou depuis une version Express) est, en français : Handle de liaison invalide ; ce message correspond, en anglais à The binding handle is invalid.

Ce problème apparaît lorsque le service Terminal Server est désactivé. Il suffit donc de relancer ce service pour que tout rentre dans l’ordre.

Pour plus de détails, voir les posts suivants (en anglais) :

Troubleshooting the “The Binding Handle Is Invalid” error in Visual Studio 2005

Explaining ‘The Binding Handle Is Invalid’

“The Binding Handle Is Invalid” error in Visual Studio 2005

Saving the state of a Graphics object

Today I discovered a new class : GraphicsContainer; it allows you to save the state of a Graphics object (transformation, clipping region, and rendering properties) and to restore it later. This class is used in conjunction with 2 pairs of methods belonging to the Graphics class: BeginContainer saves the state of the graphics object (and returns a GraphicsContainer object), EndContainer restores the state (when provided with a GraphicsContainer object). MSDN provides a sample here: http://msdn2.microsoft.com/en-us/library/azdschfw.aspx. There exists overloads of BeginContainer that accept two rectangles and unit allowing the Graphics object to be applied a new transformation after its state is saved. In the same maneer, but in a simpler way, the Graphics.Save and Graphics.Restore methods do the same job (Honestly, I don’t understand why these two pairs of methods coexist…) This led me to write a little helper class allowing to save/restore a Graphics with the using syntax. Here is how to use this class (it is just a rewritten version of the MSDN):

protected override void OnPaint( System.Windows.Forms.PaintEventArgs e) { Graphics g = e.Graphics; // Define transformation for container. RectangleF src = new RectangleF( 0f, 0f, 200f, 200f); RectangleF dest = new RectangleF( 100f, 100f, 150f, 150f); using (PaintHelper.SaveGraphics( g, dest, src, GraphicsUnit.Pixel)) { // Fill red rectangle in container. g.FillRectangle(Brushes.Red, 0.0F, 0.0F, 200.0F, 200.0F); } // Fill untransformed rectangle with green. g.FillRectangle(Brushes.Green, 0.0F, 0.0F, 200.0F, 200.0F); }

And the source code for the PaintHelper class:

using System;
using System.Drawing;
using System.Drawing.Drawing2D;

namespace Delta.Internals
{
    public static class PaintHelper
    {
        private class GraphicsBackup : IDisposable
        {
            private Graphics graphics = null;
            private GraphicsContainer container = null;

            public GraphicsBackup(Graphics g)
            {
                Init(g);
                container = g.BeginContainer();
            }

            public GraphicsBackup(
                 Graphics g, Rectangle dest, Rectangle src,
                 GraphicsUnit unit)
            {
                container = g.BeginContainer(
dest, src, unit); } public GraphicsBackup( Graphics g, RectangleF dest, RectangleF src, GraphicsUnit unit) { container = g.BeginContainer(
dest, src, unit); } private void Init(Graphics g) { if (g == null) throw new ArgumentNullException("g"); graphics = g; } public void Dispose() { graphics.EndContainer(container); } } public static IDisposable SaveGraphics(Graphics g) { return new GraphicsBackup(g); } public static IDisposable SaveGraphics(Graphics g, Rectangle dest, Rectangle src, GraphicsUnit unit) { return new GraphicsBackup( g, dest, src, unit); } public static IDisposable SaveGraphics(Graphics g, RectangleF dest, RectangleF src, GraphicsUnit unit) { return new GraphicsBackup( g, dest, src, unit); } } }

Hope this helps.

Pattern singleton thread safe en C# : c’est facile

Lu ici : http://www.dofactory.com/Patterns/PatternSingleton.aspx

Voici la manière classique d’écrire un pattern singleton thread-safe en C# :

class MySingleton
{
    private static MySingleton instance;

// Lock synchronization object
    private static object syncLock = new object();

private MySingleton() { DoSomething(); }

public static MySingleton Instance
    {
        get
        {
            // Support multithreaded applications
            // through 'Double checked locking'
            // pattern which (once the instance
            // exists) avoids locking each
            // time the method is invoked
            if (instance == null)
            {
                lock (syncLock)
                {
                    if (instance == null)
                        instance = new MySingleton();
                }
            }
            return instance;
        }
    }
}

Et maintenant, voici la manière “.NET” d’écrire ce même singleton :

class MySingleton
{
    // Static members are lazily initialized.
    // .NET guarantees thread safety for
    // static initialization
    private static readonly MySingleton instance =
                        new MySingleton();

// Constructor (private)
    private MySingleton() { DoSomething(); }

public static MySingleton Instance { get { return instance; } }
}

ça marche parce que “private static readonly” entraîne :

  • Initialisation paresseuse
  • Thread-safety garantie par .NET pour les initialisations statiques.

C’est pas beau ça ?

Comment accéder aux fichiers réels du GAC ?

Lu ici : (Using Explorer to get to physical files in the GAC http://weblogs.asp.net/jkey/archive/2003/02/25/3006.aspx), un truc idiot, mais qui marche remarquablement bien, pour voir les fichiers réels du GAC :

  • ouvrir une commande DOS, et taper subst G: %windir%\assembly
  • Si l’explorateur est ouvert, le fermer et le rouvrir, aller sur G:, et voilà, on a maintenant accès à la strucure physique du GAC !

Attention, il vaut mieux être sûr de son coup avant de faire joujou avec la structure interne du GAC…

Réparer Visual Studio 2005

Si vous avez installé Visual Studio 2005 Beta1, vous avez peut-être rencontré des problèmes dans la version finale (ou la Beta2). Plus précisément, l’IDE peut refuser de charger le “Common IDE Package” au démarrage, ou encore il peut refuser d’afficher le designer Windows Forms par exemple. Voici le genre de message que vous pouvez rencontrer :
Package Load Failure
Package 'Visual Studio Common IDE Package' has failed to load or properly ( GUID = {6E87CFAD-6C05-4ADF-9CD7-3B7943875B7C} ). Please contact package vendor for assistance. Application restart is recommended, due to possible environment corruption. Would you like to disable loading this package in the future? You may use 'devenv.exe /resetskippkgs' to re-enable package loading

Pour cette catégorie de problème, il existe le Visual Studio troubleshooting tool (gracieusement fourni par Aaron Stebner) qui peut être utilisé pour nettoyer toutes les vieilleries laissées sur votre disque dur par la Beta1 de Visual Studio, et ainsi rendre Visual Studio .NET 2005 pleinement opérationnel.
NB : cet outil devrait aussi fonctionner pour les versions Express de Visual Studio
Cet outil peut être téléchargé ici : http://astebner.sts.winisp.net/Tools/ttool.zip

Et l’article l’accompagnant : http://blogs.msdn.com/astebner/archive/2005/11/09/491118.aspx

[English version of the post]

Repairing Visual Studio .NET 2005

If you had installed Visual Studio .NET 2005 Beta1, you may run into problems using the final release (or the Beta2). More specifically, the IDE may refuse to load the “Common IDE Package” at startup, or it may be unable to show up the Windows Forms designer for instance. Some messages you may encounter may resemble this one:

Package Load Failure
Package 'Visual Studio Common IDE Package' has failed to load or properly ( GUID = {6E87CFAD-6C05-4ADF-9CD7-3B7943875B7C} ). Please contact package vendor for assistance. Application restart is recommended, due to possible environment corruption. Would you like to disable loading this package in the future? You may use 'devenv.exe /resetskippkgs' to re-enable package loading

For this category of problems, there exists the Visual Studio troubleshooting tool (gracefully provided by Aaron Stebner) which can be used to clean all the old stuff that was left on your hard drive by Beta1 release of Visual Studio and thus fully enables Visual Studio .NET 2005.
NB : this tool should also work if you encounter problems with an Express edition of Visual Studio
The tool is available for download here: http://astebner.sts.winisp.net/Tools/ttool.zip

And the article accompanying it: http://blogs.msdn.com/astebner/archive/2005/11/09/491118.aspx

[Version française]

Docking à la Visual Studio 2005

La librairie de docking de Weifen Luo a été mise à jour récemment pour supporter .NET 2 et Visual Studio 2005. On a ainsi droit à du docking très proche de ce que fait Visual Studio 2005 (c’est à dire avec les icônes de placement des fenêtres). De plus, le nouveau contrôle de menu (MenuStrip) est supporté (utile pour effectuer un merge du menu d’une fenêtre MDI fille avec le menu de son parent).

On peut télécharger cette librairie sur sourceforge : http://sourceforge.net/projects/dockpanelsuite/

Intéressant aussi (même s’il couvre une version précédente), l’article qu’il a écrit sur The CodeProject : http://www.codeproject.com/cs/miscctrl/DockManager.asp

PS : afin d’être encore plus proche du look’n’feel Visual Studio 2005, je propose un petit patch, dans le constructeur de la classe DockOutline, remplacer la couleur utilisée par DragForm.BackColor par Color.FromArgb(96, 128, 186)