Debug bootstrap
It’s taken me a good five days to get my head round the Visual Studio Debugger. For my first attempt, I tried to trap the Set Breakpoint command and go from there. Nope. Not even close. The debugger is a lot more complicated than that. It’s not made any easier by having documentation that’s aimed at a C++ implementation rather than a C# one. After a fruitless day spent trying to hack it in C#, I worked through the TextInterpreter example (which doesn’t work properly in the beta VSIP SDK I’m currently using). Even though it’s in C++, I got the general idea and was able to build a managed version reasonably easily - I’d definitely start with the C++ tutorial if I was doing it again.
The main problem with the debugger is that to build a simple (let alone one that lets you ‘edit and run’, say) you have to implement about ten COM interfaces. Then you have to build some sort of state machine on it’s own thread - plus any worker threads to handle the input and output to the Ruby interpreter itself. Each of the COM interface names starts with ‘IDebug’ so there’s IDebugProcess, IDebugProgram, IDebugProgramNode - and so on. Damned confusing. Then each interface has about ten methods and while they don’t all need coding, they need to be considered. It’s not a small job - and that’s before you get to any Ruby stuff.
One thing that struck me as I was doing the C# bits after the C++ tutorial, was how much faster it is to code in C#. Even with the ATL wizard, it still takes a lot longer than implementing the same interfaces with C#. I have to say that I’m coming round to the idea that Microsoft has done a reasonable job with COM and C#.
In passing, I found a tricky problem with the basic IDE. The Steel splash icon had vanished (this appears on the Visual Studio startup splash screen along with C#, VB, etc.). The thing was, it had been visible in the past - but no longer! It turns out that the splash icons and menu commands are installed when you do a ‘devenv /setup’ command. But setup works differently from when you just run the IDE. In particular, the DTE automation isn’t initialised. The IDE setup sequence calls the package ‘Initialize’ command before the splash icon is loaded. If you try to access automation in the package Initialise, an exception is thrown and the icon loading is never called! Worse, nothing tells you this interesting fact. You have to turn logging on and look in the log file. The solution is to test for a null DTE in Initialize: if you are running setup, this is null, otherwise it’s set to something sensible.
I’m a big fan of VSIP, but it sure isn’t simple. There’s just a lot of stuff to learn.
April 18th, 2006 at 7:11 pm
I’m about to hang a sign on my cube at work that says “Microsoft != Simple”. As much as I like .NET and Visual Studio, almost nothing is straightforward or easy when it comes to working Microsoft technologies in any depth.
I had originally thought that VS2005 would have made the task of writing plugins and extensions for Visual Studio easier than it was previously, but when I looked at the VSIP back in November my eyes just continued to glaze over. I soon gave up on the idea of creating a Rails plugin for VS.
So I really appreciate that you guys are sticking with it. I’m looking forward to the beta. Thanks.