Easy way to debug a Windows Service at startup

The typical way of debugging a Windows Service, is to attach a debugger to it after it has started. This does not work very well if one needs to debug code that only executes during the startup of the Windows Service. A useful technique I have used to debug Windows Services is to launch the debugger from the Windows Service itself if a DEBUG parameter is specified. For example:

protected override void OnStart(string[] args)

{

    // Only use this code in Debug mode.

    #if DEBUG

 

    List<string> arguments = new List<string>(args);

    if (arguments.Exists((arg) => arg.Equals("DEBUG",

        StringComparison.InvariantCultureIgnoreCase)))

    {

        // Launch Debugger if DEBUG argument is provided.

        System.Diagnostics.Debugger.Launch();

    }

 

    #endif

}

VB6 Binary Compatibility Issue on public COM fields

I discovered a very interesting VB6 ActiveX DLL issue the other day when I was trying to recompile some legacy code. Every time I would recompile a particular ActiveX DLL project, the “Break compatibility” dialog would be displayed even though the public field in question did not change.

The class that was causing this issue contained a public field that referenced an OCX control. I would never recommend doing that, but doing so should not cause Binary Compatibility to break every time it is rebuilt.

Using Microsoft’s OLE/COM Object Viewer, I discovered VB6 had declared this field (i.e. its associated methods) as IDispatch rather than IPicClip. This causes consumers of the library (including the VB6 compiler) to view the field as an Object rather than a PicClip.PictureClip.

After some trial an error, my colleague and I determined that if an OCX control is going to be available to consumers of the ActiveX DLL, the OCX library must FIRST be referenced using the References dialog before adding it to the Toolbar using the Components dialog.

After adding the OCX library using the Reference dialog first, the “Binary Compatibility” dialog does not appear when rebuilding the ActiveX DLL and the class looks as expected in Microsoft’s OLE/COM Object Viewer.

NOTE: In some situations you may not be able to reference the OCX using both the References and the Components dialogs, and I would not recommend making OCX controls available using public class fields anyway.