NppPluginNET 64-bit?

  • It looks like despite there many many plugins using NppPluginNet (originally by UFO?), there has been no maintenance and/or “authoritative” repo for the .Net plugin base/example since v0.7 about 5 years ago… So I have a couple questions:

    • Does anyone know of a shared/maintained repo for this project?
    • Does anyone know what needs to be done, if anything, to get it to work compiled for 64-bit, for the 64-bit version of Notepad++?
      • Does anyone know whether there’s a good way to get debugging information out of the plugin loading process, to get an idea of what any errors might be?

    I’ve made a couple minor attempts in this direction, but without much success:

    • I’ve switched from the included (unversioned) DllExport to the NuGet package (UnmanagedExports v1.2.7)
      ** This works - the project compiles, and the resulting plugin DLL works like it did before
    • I’ve tried to change the compilation target to x64, and that compiles successfully, but the resulting plugin DLL does not load in Notepad++ 64-bit - I get the usual “Failed to load”; “<plugin dll> is not compatible with the current version of Notepad++”

    I’m guessing there some data type issues, some Ints that need to be changed to Longs etc (presumably in NppPluginNetBase and/or NppPluginNetHelper), but I’m distinctly ignorant in this area.

    I’ll update this thread with the relevant code changes and any additional info I gather, but in the meantime I already wanted to open the discussion.

    Thanks for any insight!

  • Does anyone know of a shared/maintained repo for this project?

    @Kasper-Graversen has done some great work updating it.

    As to your other questions, I can’t say since I don’t use C#.

  • One of your questions is “Does anyone know whether there’s a good way to get debugging information out of the plugin loading process, to get an idea of what any errors might be?”. I wrote a trycatch around part of the plugin start up code and write the results into a buffer. Not the best approach but a workaround for use during plugin development. See more details on Stack Overflow.

  • Caused by problematic pointer arithmetic in

        public void Add(FuncItem funcItem)

    public void RefreshItems()

    in class FuncItems in NppPluginNETHelper.cs, like:

            IntPtr ptrPosNewItem = (IntPtr)((int)newPointer + oldSize);

    So the cast to int from type IntPtr shortens the pointer for X64, see e.g.

  • @chcg Great.

  • As mentioned above probably also an update of the included dllexport is necessary for real x64 usability. At

    the latest version there is 1.2.7. The followup nuget package with a somehow different structure is available in version 1.5 at:

  • I don’t know if this will be helpful to anyone but…

    You will also need to make the following modification for your C# plugin to work on x64 :

    • Change from int to IntPtr in the notification structure (compare what you have to what’s below)
        public struct Sci_NotifyHeader {
            /* Compatible with Windows NMHDR.
             * hwndFrom is really an environment specific window handle or pointer
             * but most clients of Scintilla.h do not have this type visible. */
            public IntPtr hwndFrom;
            public IntPtr idFrom;
            public uint code;
        public struct SCNotification {
            public Sci_NotifyHeader nmhdr;
            public int position; /* SCN_STYLENEEDED, SCN_MODIFIED, SCN_DWELLSTART, SCN_DWELLEND */
            public int ch; /* SCN_CHARADDED, SCN_KEY */
            public int modifiers; /* SCN_KEY */
            public int modificationType; /* SCN_MODIFIED */
            public int length; /* SCN_MODIFIED */
            public int linesAdded; /* SCN_MODIFIED */
            public int message; /* SCN_MACRORECORD */
            public IntPtr wParam; /* SCN_MACRORECORD */
            public IntPtr lParam; /* SCN_MACRORECORD */
            public int line; /* SCN_MODIFIED */
            public int foldLevelNow; /* SCN_MODIFIED */
            public int foldLevelPrev; /* SCN_MODIFIED */
            public int margin; /* SCN_MARGINCLICK */
            public int listType; /* SCN_USERLISTSELECTION */
            public int x; /* SCN_DWELLSTART, SCN_DWELLEND */
            public int y; /* SCN_DWELLSTART, SCN_DWELLEND */
            public int token; /* SCN_MODIFIED with SC_MOD_CONTAINER */
            public int annotationLinesAdded; /* SC_MOD_CHANGEANNOTATION */
            public int updated; /* SCN_UPDATEUI */
            public int listCompletionMethod; /* SCN_AUTOCSELECTION, SCN_AUTOCCOMPLETED, SCN_USERLISTSELECTION */
    • modify your sendmessage P/Invoke to NO LONGER use int or bool (see this page); instead use the following signature :
    [DllImport("user32.dll", CharSet = CharSet.Auto)]
    static extern IntPtr SendMessage(IntPtr hWnd, UInt32 Msg, IntPtr wParam, IntPtr lParam);

    For information, i post the modifications on my end to make it work :

    En last thing, I do use UnmanagedExport version 1.2.7.

  • hi all I’ve released but @greenzest comment perhaps reveals another version should be released soon? ;)

  • Hello @Kasper-Graversen ,

    As fas as I can tell (I didn’t try your version!) you will have the following problems with your version :

    • Your plugin will register its functions array but you will not correctly receive the notifications from npp/scintilla (all header.code will be at 0)
    • Calls to sendmessage might cause the program to freeze as stated in the pinvoke page :
    2) NEVER use "int" or "integer" as lParam. Your code WILL crash on 64-bit windows. ONLY use IntPtr, a "ref" structure, or an "out" structure.
    3) NEVER use "bool", "int", or "integer" as the return value. Your core WILL crash on 64-bit windows. ONLY use IntPtr. It's not safe to use bool - pInvoke cannot marshal an IntPtr to a boolean.


  • This code has been taken over by UFO but I really never found the time to really get into it. You are more than welcome to fix the code. My interest is for the moment merely to be able to compile my plugins with VS2015.

    After discussing with the author of Scintilla and not being able to reach the author of N++ it seems no one is interested in cleaning up the zest pool of mess called the api to N++ and Scintilla. A lot of really nice stuff could come out of taking a more structured/generative approach benefiting plugin packs of all languages. But no interest is to be traced from those authors…

  • @greenzest said:

    I think the latest merged pull request takes care of this
    happy to hear your thoughts :)

  • Just released a new and improved 64bit version

Log in to reply