In the previous post, I’ve discussed how I misused the IDisposable.Dispose() method. Here, I will present some of the ways I use the using keyword in manners that may don’t come to mind at first (I may in a few years come back to this and realize I was totally wrong, but for now, it seems to me the samples provided here may prove usefull).

According to msdn, the using statement “Defines a scope, outside of which an object or objects will be disposed“. In the remarks section of the documentation, it is also stated that “The using statement allows the programmer to specify when objects that use resources should release them“. And the next sentence: “The object provided to the using statement must implement the IDisposable interface. This interface provides the Dispose method, which should release the object’s resources“. Everything’s ok about all this, expect one little thing: by insisting on resources, it drives people to use the using keyword only with objects holding resources, or locks, or connections or whatever needs to be released to the system…

I think this statement can be used in an extensible manner for any object that:

• lives in a finite scope
• needs an action to be done when created and another one when you don’t need it any more.

For instance, when it’s dark, and I want to write something, I need some light. So I turn it on, write my post, and turn it off before going to bed. This could be writtent this way in C#:

SwitchOnLight();
WriteThisPost();
SubmitIt();   
SwitchOffLight();
GotoBed();

There are times when I’m quite tired, and I may forget to switch off the light before going to bed. This results in this code:

SwitchOnLight();
WriteThisPost();
SubmitIt();   
GotoBed();

Here, C# programmers will have recognized that some kind of Dispose() call is missing. Enters the using keyword which allows me to write:

using(Light)
{ 
    WriteThisPost();
    SubmitIt();    
}
GoToBed();

And thus, I never forget to turn off the light before going to bed.

I really like the metaphor the using keyword provides, and I’d like to be able to use it even for objects that don’t hold any system resource. As the samples below demonstrate it, there’s nothing preventing me from doing so. The main idea is that any object that needs to do something when created, and something else when released is a good candidate for the using keyword: these two tasks are implemented in the constructor and in the IDisposable.Dispose() method. The task executed in the Dispose() method hasn’t to release resources. In fact, most of the times, It just restores a saved state.

Example 1:

In most of my windows forms applications, I use a base form class providing some goodies to inheritors (one of them is a wonderfull linear gradient I apply on the background of my forms – question of taste). Among these services is WaitCursor. Usually when you want to show an hourglass cursor while processing a lengthy task, you have to follow three steps:

1. Change the cusor: this.Cursor = Cursors.WaitCursor;
2. Execute the lengthy task in a try block
3. Restore the normal cursor in a finally clause: finally { this.Cursor = Cursors.Default; }

I’ve built up a little helper class (completed with a property) which allows you to write this code, (which seems more readable to me : it’s almost well formed English):

using(WaitCursor) { /* execute lengthy task */ }

First, in the base form class, WaitCursor is a property returning an IDisposable:

protected IDisposable WaitCursor
{
         get { return new CursorProvider(this, Cursors.Wait); }
}

And CursorProvider is a private inner class also defined in the base form class:

private class CursorProvider : IDisposable
{
        Control owner = null;
        Cursor savedCursor = Cursors.Default;

        public CursorProvider(Control control, Cursor newCursor)
        {
            if (control == null)
                throw new ArgumentNullException(“control”);
            if (newCursor == null) 
                throw new ArgumentNullException(“newCursor”);

            owner = control;
            savedCursor = control.Cursor;
            control.Cursor = newCursor;
            control.Refresh();
        }

        #region IDisposable Members

        public void Dispose() { owner.Cursor = savedCursor; }

        #endregion
}

A few explanations:

• The property is returning an IDisposable instance: indeed, callers don’t have to know anything else (it is intendeed to be part of a using statement) so, why would I expose more?
• Each time the property is called, a new object is created: you can overlap as many using statements as you wish, after the last closing bracket, the correct cursor will be restored.
• We never need the object created by the call to the property, thus the using(WaitCursor) and not some using(IDisposable foo = WaitCursor).
• The class is straightforward: the constructor, after checking for null parameters, saves the current state (the current control’s cursor) then sets the new state. Inside Dispose() (which will always be called at the end of the using block, wether an exception has been thrown or not), the state is restored.

Example 2: Saving the state of a Graphics object. In this old post, I exposed a way of using the GraphicsContainer class. And I wrapped it in an IDisposable object (one time again, the idea is to save a state in the constructor, and to restore it in Dispose()).

Example 3: .NET Matters: Scope and more. In this article from MSDN Magazine, Stephen Toub explains how to code a Scope<T> class to provide transactionnal behavior. This is an advanced example of a class that fits perfectly well with the using syntax. Besides the link with this post regarding the using statement, this article also discusses many other interesting .NET concepts (and in particular, the notion of thread static members). The second short article about the Semaphore class is again an example of a pretty use of the using statement.

Back a few years ago, when I was still a new-born at C# and .NET programming, I had found myself very proud for having improved the .NET framework itself. Indeed, I had just invented the IDisposableEx interface:

public interface IDisposableEx : IDisposable
{
     bool IsDisposed { get; }
}

What did I use this interface for? It seemed to me a great improvement to be able to know whether or not an object had been disposed. And I was writing code like this:

if (!myObject.IsDisposed) myObject.Dispose();

Here lie two style errors:

1. Not so a serious one: why calling Dispose() when a using construct would make it perfectly useless (As of now, I only call Dispose() when the object is not instanciated in the method that will dispose it)?
2. The real big one: what is the use of the test on the disposed state of the object? Microsoft clearly states that a Dispose() method call should NEVER EVER fail (see msdn). One could call Dispose() thousands of times, there should never happen any exception. So, the test is useless.

On the other hand, one could argue that testing the disposed state of the object isn’t that serious… and I agree with this; in fact, what is really misconcepted in the IDisposableEx interface is not how you use it, but what it supposes can happen inside the implementor: by allowing to test the disposed state, this interface suggests that the behavior of the Dispose() method depends on the state of the object. And even worse: if you call Dispose() and the IsDisposed property was true, then Dispose() might fail! And in some of my implementations, it did! In my mind providing a means of testing was good enough, and if your app ended with an uncaught exception, it was the developper’s fault: why didn’t you test IsDisposed?… my apologies go to them… 

The correct way to handle multiple calls to Dispose() is actually to store a disposed state, but it must be inner to the object and calling code must never rely on it (so I’d  better make this private, and remove the IDisposableEx interface – from source control if I can, so that no one ever discovers my crime):

private bool disposed = false;
…
public void Dispose()
{
    if (disposed) return;

    // disposing of allocated resources
    …
    // now, don’t forget to set the disposed state
    disposed = true;
}

I hope that having revealed a part of my dark past will help you not to make that mistake, or at least will it have made you laugh a bit.

PS: I can’t think of a scenario right now where a caller should be aware of the disposed state of the callee, but in such a case, the IsDisposed property seems acceptable (if you don’t want to catch numbers of ObjectDisposedException). But I think this would be a really bad idea to provide this property as part of an interface… Or at least should this interface be named something like IDisposedStateNotifier so that developpers don’t think it modifies the IDisposable.Dispose standard behavior…

Update (2008/08/21):

As stated by SergeS in his comment, the solution I provide below (while working)  should not be used any more. Instead, replace your src/Appender/UdpAppender.cs file with the one found here:

https://svn.apache.org/viewvc/logging/log4net/trunk/src/Appender/UdpAppender.cs?revision=506603

I’m using log4net 1.2.10 for a few month now and couldn’t ever get rid of it. Today I was playing with the udp appender: I was trying to have my application send logs via udp to Log4NetViewer… and nothing happened. After having enabled the log4net debug mode (1), I could see there was something wrong with the way log4net parsed my IP (2):

log4nelog4net:ERROR [UdpAppender] Unable to send logging event to remote host ::1 on port 1234.
System.Net.Sockets.SocketException: Une adresse incompatible avec le protocole demandé a été utilisée
à System.Net.Sockets.Socket.SendTo(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, EndPoint remoteEP)
à System.Net.Sockets.UdpClient.Send(Byte[] dgram, Int32 bytes, IPEndPoint endPoint)
à log4net.Appender.UdpAppender.Append(LoggingEvent loggingEvent)

log4net was transforming my “192.168.0.2″ parameter IP into ::1, and the problem took place in the method IPAddressConverter.ConvertFrom() (the file is located under log4net-1.2.10\src\Util\TypeConverters\IPAddressConverter.cs).
The problem is that when compiled with .NET 2.0, the original code is returning the first IP address associated with the host (host itself returned by a dns lookup):

IPHostEntry host = Dns.GetHostEntry(str);
if (host != null &&
    host.AddressList != null &&
    host.AddressList.Length > 0 &&
    host.AddressList[0] != null)
{ 
    return host.AddressList[0];
}

When inspecting the content of this address list with the debugger I got:

+ [0] {::1} System.Net.IPAddress
+ [1] {192.168.0.2} System.Net.IPAddress
+ [2] {192.168.206.1} System.Net.IPAddress
+ [3] {192.168.114.1} System.Net.IPAddress

So, with the existing code, the address ::1 is selected… and the UdpAppender throws an exception To avoid this:
first I added this property to IPAddressConverter:

public bool IsIPv6Supported { get { return false; } }

note that I’m not networking aware, and thus this may be replaced by some code able to detect wether or not IP v6 is supported…
then I replaced “return host.AddressList[0];” with:

foreach (IPAddress address in host.AddressList)
{
    if ((address.AddressFamily ==
        System.Net.Sockets.AddressFamily.InterNetworkV6) &&
        !IsIPv6Supported) 
        continue;
                                
    return address;
}

This way, I return the first IPv4 address instead of the first address.Hope this helps 

(1) to do so, just add the following xml to your app.config:

<appSettings>
<add key=“log4net.Internal.Debug“ value=“true“/>
</appSettings>

(2) aproximatively translated from French into English: The used address is incompatible with the requested protocol

PS: if you want to compile the log4net visual studio project provided with the distribution, you have to apply these guidelines: http://logging.apache.org/log4net/release/building.html#vsnet-2005

Et voilà le résultat, après quelques jours passés à se gonfler d’eau :

Great news: .NET Framework 3.0 has been released!

Formerly known as WinFx, the .NET framework 3.0 is a set of (3 main) components built on top of the .NET framework 2.0 (this means that this “3rd” version is 100% compatible with .NET 2.0: it is pure .NET 2.0 code…):

• Windows communication foundation (formerly known as Indigo)
• Windows workflow foundation
• Windows presentation foundation (formerly known as Avalon)
• and the little last one: Cardspace

Grabbed from this url (may only contain most useful definitions): http://www.groupsrv.com/dotnet/about52848.html:

WM_NULL = 0×0000,
WM_CREATE = 0×0001,
WM_DESTROY = 0×0002,
WM_MOVE = 0×0003,
WM_SIZE = 0×0005,
WM_ACTIVATE = 0×0006,
WM_SETFOCUS = 0×0007,
WM_KILLFOCUS = 0×0008,
WM_ENABLE = 0×000A,
WM_SETREDRAW = 0×000B,
WM_SETTEXT = 0×000C,
WM_GETTEXT = 0×000D,
WM_GETTEXTLENGTH = 0×000E,
WM_PAINT = 0×000F,
WM_CLOSE = 0×0010,
WM_QUERYENDSESSION = 0×0011,
WM_QUIT = 0×0012,
WM_QUERYOPEN = 0×0013,
WM_ERASEBKGND = 0×0014,
WM_SYSCOLORCHANGE = 0×0015,
WM_ENDSESSION = 0×0016,
WM_SHOWWINDOW = 0×0018,
WM_CTLCOLOR = 0×0019,
WM_WININICHANGE = 0×001A,
WM_SETTINGCHANGE = 0×001A,
WM_DEVMODECHANGE = 0×001B,
WM_ACTIVATEAPP = 0×001C,
WM_FONTCHANGE = 0×001D,
WM_TIMECHANGE = 0×001E,
WM_CANCELMODE = 0×001F,
WM_SETCURSOR = 0×0020,
WM_MOUSEACTIVATE = 0×0021,
WM_CHILDACTIVATE = 0×0022,
WM_QUEUESYNC = 0×0023,
WM_GETMINMAXINFO = 0×0024,
WM_PAINTICON = 0×0026,
WM_ICONERASEBKGND = 0×0027,
WM_NEXTDLGCTL = 0×0028,
WM_SPOOLERSTATUS = 0×002A,
WM_DRAWITEM = 0×002B,
WM_MEASUREITEM = 0×002C,
WM_DELETEITEM = 0×002D,
WM_VKEYTOITEM = 0×002E,
WM_CHARTOITEM = 0×002F,
WM_SETFONT = 0×0030,
WM_GETFONT = 0×0031,
WM_SETHOTKEY = 0×0032,
WM_GETHOTKEY = 0×0033,
WM_QUERYDRAGICON = 0×0037,
WM_COMPAREITEM = 0×0039,
WM_GETOBJECT = 0×003D,
WM_COMPACTING = 0×0041,
WM_COMMNOTIFY = 0×0044 ,
WM_WINDOWPOSCHANGING = 0×0046,
WM_WINDOWPOSCHANGED = 0×0047,
WM_POWER = 0×0048,
WM_COPYDATA = 0×004A,
WM_CANCELJOURNAL = 0×004B,
WM_NOTIFY = 0×004E,
WM_INPUTLANGCHANGEREQUEST = 0×0050,
WM_INPUTLANGCHANGE = 0×0051,
WM_TCARD = 0×0052,
WM_HELP = 0×0053,
WM_USERCHANGED = 0×0054,
WM_NOTIFYFORMAT = 0×0055,
WM_CONTEXTMENU = 0×007B,
WM_STYLECHANGING = 0×007C,
WM_STYLECHANGED = 0×007D,
WM_DISPLAYCHANGE = 0×007E,
WM_GETICON = 0×007F,
WM_SETICON = 0×0080,
WM_NCCREATE = 0×0081,
WM_NCDESTROY = 0×0082,
WM_NCCALCSIZE = 0×0083,
WM_NCHITTEST = 0×0084,
WM_NCPAINT = 0×0085,
WM_NCACTIVATE = 0×0086,
WM_GETDLGCODE = 0×0087,
WM_SYNCPAINT = 0×0088,
WM_NCMOUSEMOVE = 0×00A0,
WM_NCLBUTTONDOWN = 0×00A1,
WM_NCLBUTTONUP = 0×00A2,
WM_NCLBUTTONDBLCLK = 0×00A3,
WM_NCRBUTTONDOWN = 0×00A4,
WM_NCRBUTTONUP = 0×00A5,
WM_NCRBUTTONDBLCLK = 0×00A6,
WM_NCMBUTTONDOWN = 0×00A7,
WM_NCMBUTTONUP = 0×00A8,
WM_NCMBUTTONDBLCLK = 0×00A9,
WM_KEYDOWN = 0×0100,
WM_KEYUP = 0×0101,
WM_CHAR = 0×0102,
WM_DEADCHAR = 0×0103,
WM_SYSKEYDOWN = 0×0104,
WM_SYSKEYUP = 0×0105,
WM_SYSCHAR = 0×0106,
WM_SYSDEADCHAR = 0×0107,
WM_KEYLAST = 0×0108,
WM_IME_STARTCOMPOSITION = 0×010D,
WM_IME_ENDCOMPOSITION = 0×010E,
WM_IME_COMPOSITION = 0×010F,
WM_IME_KEYLAST = 0×010F,
WM_INITDIALOG = 0×0110,
WM_COMMAND = 0×0111,
WM_SYSCOMMAND = 0×0112,
WM_TIMER = 0×0113,
WM_HSCROLL = 0×0114,
WM_VSCROLL = 0×0115,
WM_INITMENU = 0×0116,
WM_INITMENUPOPUP = 0×0117,
WM_MENUSELECT = 0×011F,
WM_MENUCHAR = 0×0120,
WM_ENTERIDLE = 0×0121,
WM_MENURBUTTONUP = 0×0122,
WM_MENUDRAG = 0×0123,
WM_MENUGETOBJECT = 0×0124,
WM_UNINITMENUPOPUP = 0×0125,
WM_MENUCOMMAND = 0×0126,
WM_CTLCOLORMSGBOX = 0×0132,
WM_CTLCOLOREDIT = 0×0133,
WM_CTLCOLORLISTBOX = 0×0134,
WM_CTLCOLORBTN = 0×0135,
WM_CTLCOLORDLG = 0×0136,
WM_CTLCOLORSCROLLBAR = 0×0137,
WM_CTLCOLORSTATIC = 0×0138,
WM_MOUSEMOVE = 0×0200,
WM_LBUTTONDOWN = 0×0201,
WM_LBUTTONUP = 0×0202,
WM_LBUTTONDBLCLK = 0×0203,
WM_RBUTTONDOWN = 0×0204,
WM_RBUTTONUP = 0×0205,
WM_RBUTTONDBLCLK = 0×0206,
WM_MBUTTONDOWN = 0×0207,
WM_MBUTTONUP = 0×0208,
WM_MBUTTONDBLCLK = 0×0209,
WM_MOUSEWHEEL = 0×020A,
WM_PARENTNOTIFY = 0×0210,
WM_ENTERMENULOOP = 0×0211,
WM_EXITMENULOOP = 0×0212,
WM_NEXTMENU = 0×0213,
WM_SIZING = 0×0214,
WM_CAPTURECHANGED = 0×0215,
WM_MOVING = 0×0216,
WM_DEVICECHANGE = 0×0219,
WM_MDICREATE = 0×0220,
WM_MDIDESTROY = 0×0221,
WM_MDIACTIVATE = 0×0222,
WM_MDIRESTORE = 0×0223,
WM_MDINEXT = 0×0224,
WM_MDIMAXIMIZE = 0×0225,
WM_MDITILE = 0×0226,
WM_MDICASCADE = 0×0227,
WM_MDIICONARRANGE = 0×0228,
WM_MDIGETACTIVE = 0×0229,
WM_MDISETMENU = 0×0230,
WM_ENTERSIZEMOVE = 0×0231,
WM_EXITSIZEMOVE = 0×0232,
WM_DROPFILES = 0×0233,
WM_MDIREFRESHMENU = 0×0234,
WM_IME_SETCONTEXT = 0×0281,
WM_IME_NOTIFY = 0×0282,
WM_IME_CONTROL = 0×0283,
WM_IME_COMPOSITIONFULL = 0×0284,
WM_IME_SELECT = 0×0285,
WM_IME_CHAR = 0×0286,
WM_IME_REQUEST = 0×0288,
WM_IME_KEYDOWN = 0×0290,
WM_IME_KEYUP = 0×0291,
WM_MOUSEHOVER = 0×02A1,
WM_MOUSELEAVE = 0×02A3,
WM_CUT = 0×0300,
WM_COPY = 0×0301,
WM_PASTE = 0×0302,
WM_CLEAR = 0×0303,
WM_UNDO = 0×0304,
WM_RENDERFORMAT = 0×0305,
WM_RENDERALLFORMATS = 0×0306,
WM_DESTROYCLIPBOARD = 0×0307,
WM_DRAWCLIPBOARD = 0×0308,
WM_PAINTCLIPBOARD = 0×0309,
WM_VSCROLLCLIPBOARD = 0×030A,
WM_SIZECLIPBOARD = 0×030B,
WM_ASKCBFORMATNAME = 0×030C,
WM_CHANGECBCHAIN = 0×030D,
WM_HSCROLLCLIPBOARD = 0×030E,
WM_QUERYNEWPALETTE = 0×030F,
WM_PALETTEISCHANGING = 0×0310,
WM_PALETTECHANGED = 0×0311,
WM_HOTKEY = 0×0312,
WM_PRINT = 0×0317,
WM_PRINTCLIENT = 0×0318,
WM_HANDHELDFIRST = 0×0358,
WM_HANDHELDLAST = 0×035F,
WM_AFXFIRST = 0×0360,
WM_AFXLAST = 0×037F,
WM_PENWINFIRST = 0×0380,
WM_PENWINLAST = 0×038F,
WM_APP = 0×8000,
WM_USER = 0×0400,
WM_REFLECT = WM_USER + 0×1c00

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

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.

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 ?

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…