Testing nppPluginList for new/updated plugin

PeterJones

In the old days (ie, the last time I did an update to a plugin last December), I was able to follow the plugin list instructions to verify that a plugin would work with the nppPluginList before submitting to that repo. Specifically: download a recent DEBUG build, run that in a portable where plugins\Config\nppPluginList.json is the updated JSON with the hash for my new/updated plugin, run the DEBUG executable, install using plugin list.

But when I tried with a v8.9.8 DEBUG build, when I would pick either my new/updated plugin, or pick an existing plugin (one that works just find to install through the DLL version), it just exits the portable, but never initiates the download nor restarts the portable Notepad++ DEBUG executable.

I know this used to work right. I double-checked the SHA256 – both from GitHub release attachment display, and as calculated identically by Tools > SHA-256 > Generate from file – matches what I put in the JSON. I double-checked to make sure nothing in my portable directory has the Mark of the Web. So I cannot figure out anything I am doing wrong.

Did one of the security updates, where it’s checking more things under the hood, break the plugin-list JSON testing procedure?

Has anyone else tried the Plugins Admin verification procedure recently (@Coises, for example, with Columns++ 1.3.3 or @rdipardo with PreviewHTML 1.4.6)? If so, did it work for you? Or did you have to do something special to get the test to work? Or are you just so experienced that you stopped trying to test the nppPluginList.JSON before submitting?

Coises

@PeterJones said:

Has anyone else tried the Plugins Admin verification procedure recently

Yes, but I’ve been using the same copies of Notepad++ for a long time now: portable 8.7, x86 and x64. By now I’ve forgotten how I got them, but I’m pretty sure I didn’t build them, I got them from a link someone here (possibly you) gave me.

I do check every time, because about one time in five I seem compelled to make a silly error.

PeterJones

@Coises .

I’ve forgotten how I got them, but I’m pretty sure I didn’t build them, I got them from a link someone here (possibly you) gave me.

It’s easy to get the debug builds for recent builds – the user manual link explains how – but for older versions, the GitHub artifacts expire.

I guess to find which version caused the procedure to stop working, I will have to do a search through versions from December until now, and figured out the last version that worked by following the procedure. Once I know that, I can file a bug (or ask if there’s an intended update to that procedure)… I guess I am building a lot of debug versions of N++ today. ;-)

I’ve been using the same copies of Notepad++ for a long time now: portable 8.7

I guess I know I don’t have to search back any farther than that, anyway. :-) (Actually, since I know it was working in Dec 2025, I shouldn’t need to go back before v8.8.8, hopefully.)

rdipardo

@PeterJones said:

[W]hen I tried with a v8.9.8 DEBUG build, when I would pick either my new/updated plugin, or pick an existing plugin (one that works just find to install through the DLL version), it just exits the portable, but never initiates the download nor restarts the portable Notepad++ DEBUG executable.

I have also noticed what you describe, and I assumed the cause was whatever security hardening they did to WinGUP (or the cURL library it depends on) after the server takeover incident last year.

I built my own debug copy of GUP.exe and had no issue following the user manual’s instructions.

I guess to find which version caused the procedure to stop working,

Starting with the first post-incident release would be sensible.

PeterJones

@rdipardo ,

I built my own debug copy of GUP.exe and had no issue following the user manual’s instructions.

With that idea, I took the released gup.exe and libcurl.dll from 8.7 portable, and put it in my debug copy of 8.9.8 portable, and the pluginsAdmin debug procedure worked. So it’s definitely on the GUP end of things. So that’s the right path to go down for finding the culprit.

Thanks.

PeterJones

@rdipardo ,

So I forked the project and updated the github action to save the debug artifacts as well as the release artifacts: when I use that artifact, then the newest debug notepad++.exe combined with the newest debug gup.exe is successful at running the sequence.

Thanks for the insight, I wil have to update the Manual to give instructions on using a debug build for gup.exe as well.

Also, I am curious: when you did your own debug build (locally, I assume), what procedure did you do for the build? Because when I told it to build the Solution in VS, it complained about the static libcurl library being missing. I saw in the action workflow that libcurl is built before the main project, but I wasn’t able to replicate a successful build of libcurl on my local machine (I tried the visual studio powershell, and tried to run the same command line that the workflow uses, but it failed on me). If you’ve got steps that work for doing a local debug build, that would be helpful. If it was too long ago, and you don’t remember how you got the libcurl portion, that’s fine.

rdipardo

@PeterJones said:

[W]hen I told it to build the Solution in VS, it complained about the static libcurl library being missing.

I only bothered with a 64-bit build; I can reproduce the link error if I try building GUP.exe for the Win32 platform.

Notice where the Visual C++ project file looks for libraries; the path for 32-bit builds is rooted at ..\curl\build\x86\. However, cURL’s build workflow uses CMake to generate a Visual C++ project on the fly. If you just let Visual Studio have at it, the automatic output directory will have the name "Win32 "!!!

The GitHub workflow ensures a correctly named output directory by passing it to the CMake command line. You would have to do the same locally for a successful 32-bit build.

rdipardo

@PeterJones said:

If you’ve got steps that work for doing a local debug build, that would be helpful.

> where cmake
C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe

> type .\build_gup.ps1
param (
    [string]$Configuration = "Debug",
    [string]$Platform = "x64"
)
if (-not $(Test-Path "${PSScriptRoot}\wingup\.git")) {
    git clone --single-branch https://github.com/notepad-plus-plus/wingup.git wingup
}
try {
    pushd "${PSScriptRoot}\wingup"
    $CmakeArchParam=$(if ("$Platform" -imatch "x86") {"Win32"} else {"$Platform"})
    $LibPlatform=$(if ("$Platform" -imatch "Win32") {"x86"} else {"$Platform"})
    cmake -S ".\curl" -B ".\curl\build\$LibPlatform" -A $CmakeArchParam `
        -DBUILD_SHARED_LIBS=OFF `
        -DCURL_STATIC_CRT=ON `
        -DBUILD_CURL_EXE=OFF `
        -DCURL_USE_SCHANNEL=ON `
        -DCURL_USE_OPENSSL=OFF `
        -DBUILD_TESTING=OFF `
        -DUSE_LIBPSL=OFF `
        -DCURL_USE_LIBPSL=OFF `
        -DUSE_NGHTTP2=OFF `
        -DUSE_LIBIDN2=OFF

    cmake --build ".\curl\build\$LibPlatform" --config $Configuration
    pushd vcproj
    msbuild GUP.sln /v:m /p:configuration=$Configuration /p:platform=$LibPlatform
    popd
} catch {
    $_.InvocationInfo.PositionMessage; $_.Exception.Message
} finally {
    popd
}

> powershell .\build_gup.ps1 Debug x86
# ...