How to debug plugins during development?



  • MessageBox is rather primitive, but quite effective. I wrote a debugging function mprintf with the same arguments as printf, which formats a buffer using sprintf and then passes it to MessageBox.

    Unless the change of focus resulting from the display of the message box interferes with your work, this should help.

    David



  • You can also do source-level debugging.

    Build a debug version of your DLL and put it in the NPP plugins directory. Then, after you start up NPP, Go to Visual Studio and select Debug->Attach To Process… and then find the instance of NPP you just started and select it.

    Now you can set breakpoints in your plugin and debug away. :-)



  • To make the source level debugging easier you can also set a post-build event to copy the DLL to the plugins directory and set the N++ exe as the command to run when debugging. After that is as simple as pressing F5.



  • @dail
    Nice. I had no idea it could be so easily done. Thanks for the tip.



  • I’m trying to get source level debugging working in VS2017 and the current C# demo plugin templates from kbilsted/NotepadPlusPlusPluginPack.Net.

    It builds and runs fine (Debug/x86), and in VS I can attach to a running instance of notepad++ and hit breakspoints etc. Marvellous!

    However I just can’t figure out how to get the debugger to work when I try and launch in the VS IDE with F5.

    I’ve pointed VS to the exact same notepad++.exe, and it launches fine on F5, but the breakpoints just dont fire.
    In VS the breakpoints display as a hollow circle (instead of solid red dot) and reads
    The breakpoint will not currently be hit. No executable code of the debugger’s target code is associated with this line.
    Possible causes include: conditional compilation, compiler optimisations, or the target architecture of this line is not supported by the current debugger code type.

    Imgur

    If I look at “modules” screen in VS I can see the pdb is found just fine, but there are two copies of the demo.dll loaded.
    Imgur
    I notice the 2nd one has “The module did not load at the default load address.”
    Both lines show the same debug symbols (C:\6\Dev\npp.7.4.2.bin\plugins\Demo.pdb) and are connected to the same npp PID (running from C:\6\Dev\npp.7.4.2.bin\notepad++.exe).

    If I then “Stop Debugging” in VS and instead launch C:\6\Dev\npp.7.4.2.bin\notepad++.exe directly from Explorer, I can simply attach VS and debug successfully. In this case modules view shows only a single demo.dll…
    Imgur

    I’ve been experimenting all day to try and get it working - cleaning, deleting obj, various arcane settings, a fresh copy of the demo source.

    Any suggestions?



  • @moon6969

    It’s been a while since I used dotnet languages but as far as I remember there
    is a default settings which prevents dependencies from building at compile time.
    Means only the startup project gets compiled but dependencies are build at runtime.
    Could this be your issue as well?

    Cheers
    Claudia



  • Thanks Claudia.

    I did some more experiments with the “Only build startup projects and dependencies on Run” setting, but it had no effect. I believe this setting is only relevant in bigger solutions… in my test case there are no dependencies and only one project!

    To get some perspective I downloaded a more up to date C# plugin: phdesign/NppToolBucket (nice work thanks Paul!)

    The provided .sln file worked flawlessly on VS2017 without modifcation (other than pointing it to my test notepad++ instance).

    So I compared in detail NotepadPlusPlusPluginPack.Net and NppToolBucket and came to the conclusion my issue is probably in the DllExport section and possibly related to using VS2017 rather than VS2015.

    My head hurts now, so I am just going to run with NppToolBucket as my learning base!

    Cheers.



  • I got the same issue with a new plugin after changing my NPP source to v7.5.6.

    It seems to be caused by the C# plugin being targeted to “Any CPU” in the configuration manager - even though the C# project properties showed “Platform: Active (x86)”, the “Platform target” was “Any CPU”.

    To change it I had to open the configuration manager and create a new x86 Platform on the C# plugin line as shown here:
    Imgur



  • Got this issue again with VS2017 and NPP 7.6.3 source.
    The issue appears to be related to the NPP projects default Debugger Type setting of “Auto”… so it was assuming the C++ Native debugger based on the NPP exe.
    Changing this to “Managed Only” or “Mixed” sorted it…
    NPPdebugType



  • hello @moon6969

    thank you for taking the time to share every of your debugger solutions, including vs2017 now.
    it’s very helpful and appreciated. 👍


Log in to reply