Aargh…

I’m spending some time today adding .NET 2.0 features to Help Builder’s type import routines. For the most part I expected this to go real smoothly but as it turns out a lot more work than I anticipated, no thanks to VS.NET which is getting in the way...

It looks like VS.NET 2005 RC does not want to debug COM objects properly. I have the debugger set up properly to debug into some specific code that does type parsing and a few breakpoints set. The debugger stops, but as soon as I start stepping through the code the debugger is hopelessly lost. It’s executing some completely different code than what is actually showing in the debugger. The code steps into lines of code that are failing if expressions and not stepping into my user code.

For example check out the debugger display below:
 

The code is going into GetAllObjects() even through aObjects in this situation is NOT null. Trying to step into GetAllObjects results in the debug pointer jumping into the whitespace below the GetAllObjects call.

I made sure that I’m debugging the right version of the runtime – the COM Object is loading the proper .NET runtime as set up with the proper App.Config file – in this case for VFP.EXE, which looks like this:

<?xml version="1.0"?>

<configuration>

 <startup>

 <supportedRuntime version="v2.0.50727"/>

 <supportedRuntime version="v1.1.4322"/>

 <supportedRuntime version="v1.0.3705"/>

</startup>

</configuration>

Note the addition of the 2.0 version at the top, so that Help Builder will try to load any COM objects with the 2.0 version first. This is required in order to read any .NET 2.0 assemblies which are not readable with .NET 1.1 Reflection.

The code runs fine but the debugger doesn't work correctly in this code. The net effect is that I can't debug any COM invoked .NET assemblies. Very annoying. Luckily everything works fine if I access the code directly from .NET so I had to set up a WinForm app for testing as a front end. I suppose that's easier to work with anyway, but this stuff should work.

BTW, I've had a bunch of problems with the Debugger in the betas so far especially in WinForms applications. The Application Host process that VS.NET uses behaves very differently from an app directly run from the desktop directly, so beware of little subtle differences in the way security and especially threading works. I've taken to turning off the Application host option for most of my desktop code I'm working on.