Debugging an Eiffel .NET DLL within Visual Studio

We have a Visual Basic GUI application written many years ago. A couple of years ago, we wrote an Eiffel .NET DLL which provides a lot of the core functionality needed by the VB application. When everything is working this is great, but when something goes wrong, it's very frustrating for the VB developers.

The other day, I supplied a new version of the DLL, built with EiffelStudio 6.0. A VB developer reported that the application was now getting a StackOverflowException. The exception was originating somewhere within the Eiffel DLL. Unlike exceptions thrown by the VB application itself, the Visual Studio debugger didn't break at the offending line of Eiffel code. There was nothing the VB developer could do, except show the problem to an Eiffel developer (me), who then had to figure out how to simulate the problem in pure Eiffel, or maybe trace the program flow with debug statements. Needless to say, this can be tedious and time-consuming, so we decided to look for a easier approach.

Visual Studio gets its debugging information from .pdb files. The finalized assembly (let's call it a) consisted of two DLLs: a.dll and its unmanaged helper liba.dll. Both had to be deployed with the VB executable. I wanted to provide an a.pdb file too, in the hope that Visual Studio would be able to do something useful with it.

This turned out to be very easy. All I had to do was open EiffelStudio's Project Settings window, select the Target node, set Line Generation to True, and then finalize the project again. The size of a.dll had grown by about 15%, and I now had the desired a.pdb file.

This seemed too good to be true, but I copied the three new files to my VB project directory to see what Visual Studio would do. I rebuilt the VB project and ran it in the Visual Studio debugger. Amazingly, when the stack overflow occurred, it dropped me right into the offending line of code, as shown in the attached image. The actual cause of the problem took many hours of debugging, but I was able to single-step through the code, set breakpoints, inspect variables, set watches, etc. It stepped in and out of the VB and Eiffel code almost seamlessly. How cool is that!

The only problems I found were that the Eiffel code had no syntax highlighting (which is to be expected, because EiffelEnvision doesn't exist yet for Visual Studio 2005); and that the Result variable always showed null in once functions.