SQLinForm dll not compatible with the current version o N++

Guido Thelen

Hello everybody,
I wish everybody a Happy New Year 2021!

After a big refactoring job I want to publish a new Releaseof SQLinForm SQL Formatter plugin.
I worked with Visual Studio 2019 to develop the new release.
Now I get the above mentioned error ‘SQLinForm.dll not compatible with the current version o N++’
Are there any restrictions regarding to C++ version supported by N++ or any other restrictions I should be aware of.

Regards
Guido

PeterJones

@Guido-Thelen ,

Not sure. You should be able to use any recent VS to compile, AFAIK. But I have never tried to release a plugin.

My gut reaction was: are you sure you were using the 64 bit DLL with the 64bit Notepad++? And what version of Notepad++ were you using for testing.

Ekopalypse

@Guido-Thelen said in SQLinForm dll not compatible with the current version o N++:

not compatible with the current version o N++

Is that the whole message you are getting?
Normally you should get an additional info what is causing it.

Guido Thelen

@Ekopalypse thanks for your answer.
Below is a screenshot of the message.

Regards
Guido

Guido Thelen

@PeterJones thanks for your answer. I will check this in detail
Regards
Guido

PeterJones

@Guido-Thelen ,

I just ran a couple quick experiments (downloaded the released versions of your plugins using plugins admin):

it loads fine in either, and gives

If I copy over the 32bit DLL and put it in the folder for the 64bit Notepad++, NPP gives me the error:

That’s similar, but is explicit about the 32-bit nature of the plugin DLL. I think “Failed to load” is indicating something different – a bug in your source code for the plugin, probably.

You said you did a lot of refactoring, so you probably got something wrong during the refactoring.

It might be a good idea for you to try to recompile the 5.3.35 version of your code in your existing setup, and make sure that you can still compile it properly and get it to work. Then compare VS settings between the two, to make sure that there isn’t some missing external resource or option difference.

I know that sometimes you cannot avoid doing “major refactoring” when adding a new feature or changing libraries you depend on. But when at all possible in my software development, I try to make incremental changes and tests, and make sure everything still works at various stages along the way, because that helps prevent issues like this.

Guido Thelen

thanks. I will investigate during the weekend

Guido Thelen

@PeterJones I removed some of my changes. It is still not starting but I am getting a more clear error message.
“This ANSI plugin is not compatible with your Unicode Notepad++”
It looks like I am missing the point where I turn my Plugin into an UTF-8 plugin.

Any idea where I can find this switch?

Regards
Guido

Guido Thelen

and this is the content from UnmanagedExports

// NPP plugin platform for .Net v0.93.87 by Kasper B. Graversen etc.
using Kbg.NppPluginNET.PluginInfrastructure;
using NppPlugin.DllExport;
using System;
using System.Runtime.InteropServices;

namespace Kbg.NppPluginNET
{
    internal class UnmanagedExports
    {
        [DllExport(CallingConvention = CallingConvention.Cdecl)]
        private static bool isUnicode()
        {
            return true;
        }

        [DllExport(CallingConvention = CallingConvention.Cdecl)]
        private static void setInfo(NppData notepadPlusData)
        {
            PluginBase.nppData = notepadPlusData;
            Main.CommandMenuInit();
        }

        [DllExport(CallingConvention = CallingConvention.Cdecl)]
        private static IntPtr getFuncsArray(ref int nbF)
        {
            nbF = PluginBase._funcItems.Items.Count;
            return PluginBase._funcItems.NativePointer;
        }

        [DllExport(CallingConvention = CallingConvention.Cdecl)]
        private static uint messageProc(uint Message, IntPtr wParam, IntPtr lParam)
        {
            return 1;
        }

        private static IntPtr _ptrPluginName = IntPtr.Zero;

        [DllExport(CallingConvention = CallingConvention.Cdecl)]
        private static IntPtr getName()
        {
            if (_ptrPluginName == IntPtr.Zero)
                _ptrPluginName = Marshal.StringToHGlobalUni(Main.PluginName);
            return _ptrPluginName;
        }

        [DllExport(CallingConvention = CallingConvention.Cdecl)]
        private static void beNotified(IntPtr notifyCode)
        {
            ScNotification notification = (ScNotification)Marshal.PtrToStructure(notifyCode, typeof(ScNotification));
            if (notification.Header.Code == (uint)NppMsg.NPPN_TBMODIFICATION)
            {
                PluginBase._funcItems.RefreshItems();
                Main.SetToolBarIcon();
            }
            else if (notification.Header.Code == (uint)NppMsg.NPPN_SHUTDOWN)
            {
                Main.PluginCleanUp();
                Marshal.FreeHGlobal(_ptrPluginName);
            }
            else
            {
                Main.OnNotification(notification);
            }
        }
    }
}

Ekopalypse

@Guido-Thelen

this error happens when isUnicode function is not exported.
isUnicode should always return True.

Guido Thelen

@Ekopalypse ok. I checked the UnmanagedExports class and it contains isUnicode function (see code snippet above)

Ekopalypse

but is it really exported??
Tools like dumpbin /exports can show if the function is really exported.

Ekopalypse

Something like this

dumpbin /exports D:\PortableApps\Npp\plugins\PythonScript\PythonScript.dll

Dump of file D:\PortableApps\Npp\plugins\PythonScript\PythonScript.dll

File Type: DLL

  Section contains the following exports for PythonScript.dll

    00000000 characteristics
    FFFFFFFF time date stamp
        0.00 version
           1 ordinal base
           7 number of functions
           7 number of names

    ordinal hint RVA      name

          1    0 000452B0 PyInit_Npp
          2    1 000434E0 beNotified
          3    2 00042730 getFuncsArray
          4    3 00042720 getName
          5    4 0000A420 isUnicode
          6    5 00043880 messageProc
          7    6 00042570 setInfo

  Summary

       16000 .data
        D000 .pdata
       6B000 .rdata
        2000 .reloc
        9000 .rsrc
       F7000 .text

Guido Thelen

indeed. this could be the problem. When I build the same solution with VS2015 instead of VS2019, it works (without changing anything). Probably the Export is not done in VS2019.

Ekopalypse

@Guido-Thelen
last time I played with C# plugin interface there was an
extra export step at the end. I can’t remember its name.
Maybe in 2019 it does have to be called slightly different!?

Guido Thelen

@Ekopalypse thx. Will check this. Where can I find dumpbin?

Ekopalypse

should be available from a developer command prompt
Is part of VS environment.

Guido Thelen

@Ekopalypse ok. found it. it is strange. the version built with VS2015 does not have the isUniCode function exported, but it works

Dump of file C:\Users\guido\Documents\SQL\C#SQLinForm\SQLinFormNpp - Kopie (3)\SQLinFormNpp\bin\Release\SQLinFormNpp.dll

File Type: DLL

  Summary

        2000 .reloc
        2000 .rsrc
        2000 .sdata
       F6000 .text

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community>

So, it looks like it is as you wrote: the export is missing

Ekopalypse

that is strange, indeed. How can npp access non-existent function pointers??
Let me check this again.

Ekopalypse

@Guido-Thelen If I download the version available from plugin admin I do see the functions exported.

File Type: DLL

  Section contains the following exports for \SQLinFormNpp64.dll

    00000000 characteristics
    5DD1422F time date stamp Sun Nov 17 13:50:55 2019
        0.00 version
           0 ordinal base
           6 number of functions
           6 number of names

    ordinal hint RVA      name

          5    0 000EF2CE beNotified
          2    1 000EF2AA getFuncsArray
          4    2 000EF2C2 getName
          0    3 000EF292 isUnicode
          3    4 000EF2B6 messageProc
          1    5 000EF29E setInfo