<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://www.eiffelroom.com" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>eiffelroom - Debugging an Eiffel .NET DLL within Visual Studio - Comments</title>
 <link>http://www.eiffelroom.com/blog/peter_gummer/debugging_an_eiffel_net_dll_within_visual_studio</link>
 <description>Comments for &quot;Debugging an Eiffel .NET DLL within Visual Studio&quot;</description>
 <language>en</language>
<item>
 <title>VS 2005 syntax highlighting</title>
 <link>http://www.eiffelroom.com/blog/peter_gummer/debugging_an_eiffel_net_dll_within_visual_studio#comment-311</link>
 <description>&lt;p&gt;The thought crossed my mind that it would be nice. Apart from anything else, the free availability of Eiffel syntax highlighting in VS would help to promote the language, in a small way.&lt;/p&gt;

&lt;p&gt;By the way, the squiggly red syntax error underlining in my screen shot is because I&#039;ve told VS to treat &lt;strong&gt;.e&lt;/strong&gt; files as C# files. This is to prevent an annoying dialog that pops up asking me what encoding to use every time it opens a &lt;strong&gt;.e&lt;/strong&gt; file. I just ignore the red underlining.&lt;/p&gt;

</description>
 <pubDate>Thu, 26 Jul 2007 15:52:31 -0700</pubDate>
 <dc:creator>peter_gummer</dc:creator>
 <guid isPermaLink="false">comment 311 at http://www.eiffelroom.com</guid>
</item>
<item>
 <title>VS 2005 syntax highlighting</title>
 <link>http://www.eiffelroom.com/blog/peter_gummer/debugging_an_eiffel_net_dll_within_visual_studio#comment-308</link>
 <description>&lt;p&gt;I&#039;ll see what we can do to make the syntax highlighting for VS 2005 freely available since we do use it at Eiffel Software.&lt;/p&gt;

</description>
 <pubDate>Thu, 26 Jul 2007 08:03:40 -0700</pubDate>
 <dc:creator>manus_eiffel</dc:creator>
 <guid isPermaLink="false">comment 308 at http://www.eiffelroom.com</guid>
</item>
<item>
 <title>Debugging an Eiffel .NET DLL within Visual Studio</title>
 <link>http://www.eiffelroom.com/blog/peter_gummer/debugging_an_eiffel_net_dll_within_visual_studio</link>
 <description>&lt;p&gt;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&#039;s very frustrating for the VB developers.&lt;/p&gt;

&lt;p&gt;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 &lt;code class=&quot;geshifilter vbnet&quot;&gt;StackOverflowException&lt;/code&gt;. The exception was originating somewhere within the Eiffel DLL. Unlike exceptions thrown by the VB application itself, the Visual Studio debugger didn&#039;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 &lt;code class=&quot;geshifilter eiffel&quot;&gt;&lt;span style=&quot;color: #603000;&quot;&gt;debug&lt;/span&gt;&lt;/code&gt; statements. Needless to say, this can be tedious and time-consuming, so we decided to look for a easier approach.&lt;/p&gt;

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

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

&lt;p&gt;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!&lt;/p&gt;

&lt;p&gt;The only problems I found were that the Eiffel code had no syntax highlighting (which is to be expected, because EiffelEnvision doesn&#039;t exist yet for Visual Studio 2005); and that the &lt;code class=&quot;geshifilter eiffel&quot;&gt;&lt;span style=&quot;color: #800080;&quot;&gt;Result&lt;/span&gt;&lt;/code&gt; variable always showed &lt;code class=&quot;geshifilter vbnet&quot;&gt;&lt;span style=&quot;color: #FF8000;&quot;&gt;null&lt;/span&gt;&lt;/code&gt; in &lt;code class=&quot;geshifilter eiffel&quot;&gt;&lt;span style=&quot;color: #0600FF; font-weight: bold;&quot;&gt;once&lt;/span&gt;&lt;/code&gt; functions.&lt;/p&gt;

</description>
 <comments>http://www.eiffelroom.com/blog/peter_gummer/debugging_an_eiffel_net_dll_within_visual_studio#comments</comments>
 <category domain="http://www.eiffelroom.com/tag/net_debugging">.NET debugging</category>
 <enclosure url="http://www.eiffelroom.com/files/DebuggingEiffelInVS2005.PNG" length="104787" type="image/png" />
 <pubDate>Wed, 25 Jul 2007 23:47:54 -0700</pubDate>
 <dc:creator>peter_gummer</dc:creator>
 <guid isPermaLink="false">203 at http://www.eiffelroom.com</guid>
</item>
</channel>
</rss>
