Ahh sweet debugging monkey..

I am building this C++ to C# bridge prototype to in order to investigate what it takes to allow IronPython or .NET assemblies as plugins for a big C++ code base.

All was well in the prototype but when I started integrating it into our code I started running into all kinda of crap. A series of mysterious EEMessageException etc. My VS2008 would indicate that an exception was thrown, from some hex address and the stacktrace would point to some random location for the source. This was pretty frustrating as that EEMessageException was not listed in the SDK.

.NET errors are also logged in the Event manager. However, the information there was useless (it just said Fatal Error). No dice there as well.

After doing all kinds of things (basically re-reading the Pratschner book) and starting with implementing my custom AppDomainManager , I started seeing some changes: different exceptions. Since I defined my own AppDomainManager which had to be loaded from a .NET dll, the exception changed to EEFileNotFileException. Again, no details whatsoever, but atleast now I can figure out that the problem is definitely that the assembly containing my custom AppDomainManager was not being loaded. Some more inspired googling later, I found this gem: Apparently I need to set my debugging type to Mixed (It was being set to auto and it obviously was not auto enough).

Now, the debug information was fantastic. I had specified blah.dll as the containing assembly and the debug dialog indicated that the missing files were blah.dll.DLL and blah.dll.exe. The methods simply expect the name of the assembly without any suffixes (makes sense when you think in terms of mono where it should ideally search for .so files).

Anyhow, once I figured this out, the debugger pointed out all the boneheaded things I had done (keeping assembly names in sync across C++, C# and python) it was easy to get it all working again and I can sleep well today :-).