Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

VS.NET 2005 Debugger chokes on COM/.NET Interop Debugging


:P
On this page:

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.

 

This stuff gets confusing in a hurry. I’m still trying to figure out how to do the versioning of all of this. There’s the Reflection wrapper/.NET Helper object I have set up as well as the Help Builder Addin. The add-in will need to run for a specific version of .NET with the specific version of the runtime, so I’ll surely have to duplicate the DLLs.

 

Yeah right, who said that .NET versioning was going to make life so much easier? <g>...

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.

 

 

 


The Voices of Reason


 

Rick Strahl
October 27, 2005

# re: VS.NET 2005 Debugger chokes on COM/.NET Interop Debugging

Ok, I figured out my problem and well, it was user error.

This is a problem that gets me everytime though. My dev environment compiles the DLL into my Help Builder runtime directory and registers the COM object there.

However, to ensure the right version to be used I use a .Config file and that causes the DLL to try and load from the currently executing applicatoin path which in this case is Visual FoxPro (in the VFP install directory).

So VS was launching the copy out of the VFP directory which was old causing the funky debugging behavior which now makes sense. The debugger was debugging with the wrong PDB file.

Aarrgh. THis is all the more galling because I've done the same exact thing about a year ago, and it took forever to figure out. Now I forgot again...

Moral of the story - always have a version info method that can tell you exactly where the COM interop assembly is running from and what version of .NET it's running!!!

# DotNetSlackers: VS.NET 2005 Debugger chokes on COM/.NET Interop Debugging


West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2020