Debugging Notes

Debugging user code in your add-in

I don't usually have issues debugging the managed add-in's user-defined functions and commands.

There is a trick needed to set up the debugging when using the Express editions - the project file must be edited by hand to set the native executable to run. This is discussed here:

Debugging the Excel-DNA integration libraries

This is from a discussion on the Google group -

Debugging the managed Excel-DNA integration libraries can be a bit tricky sometimes.

When recompiling (only for the Debug - Win32 configuration), you'll see the ExcelDna.Loader.dll and ExcelDna.Integration.dll copied to the output (Source\ExcelDna\Debug) directory. Then, when the add-in is loaded from there, these assemblies are loaded from the files and not the packed versions. So you need not fiddle with the packing for the debugging to work - you just need those assemblies as files next to the .xll - then the files are loaded and the packed versions ignored. They have to be up-to-date though, else the debugger won't match your code with the loaded .dlls.

The following works for me:
  • Make sure you rebuild everything - when you set up 'ExcelDna.Integration' for debugging, the ExcelDna project might not rebuild, so the ExcelDna.Integration in the (Source\ExcelDna\Debug) directory might not be updated. When in doubt I just press Build->Batch Build->Rebuild All, and then I'm sure it's OK.
  • I start Excel on its own, then attach the debugger, then load the add-in. This seems more reliable than starting the debugger
  • Another trick I have use sometimes is to put a Debug.Assert(false) somewhere in the loading path - this allows you to select the debugger when the assertion failure breaks the process.

Last edited Jun 22, 2012 at 11:37 PM by govert, version 2


callidex Feb 19, 2014 at 11:05 AM 
Alongside the Debug.Assert(false) trick you can also call System.Diagnostics.Debugger.Launch() method