Skip to content

v1.0.0 implementation: panel persistence, smart-purge, CI fix#3

Merged
JamesShaver merged 1 commit into
mainfrom
v1.0.0-implementation
May 20, 2026
Merged

v1.0.0 implementation: panel persistence, smart-purge, CI fix#3
JamesShaver merged 1 commit into
mainfrom
v1.0.0-implementation

Conversation

@JamesShaver
Copy link
Copy Markdown
Owner

Summary

  • Eagerly register the dockable panel on NPPN_READY so Notepad++'s saved docking layout (visibility, position) is restored on next launch.
  • Suspend auto-removal during NPPN_BEFORESHUTDOWN so the per-tab close notifications fired by Notepad++ at shutdown don't strip every open file from the virtual tree.
  • Smart-purge unsaved-buffer entries at startup: keep entries whose buffer still exists (Notepad++ session-backup case), drop only the genuinely dead ones.
  • Dispose the panel form and tab icon explicitly on NPPN_SHUTDOWN.
  • Fix CI: drop --no-build from the test step so dotnet builds the SDK-style test project; the prior msbuild /p:Platform=x64 step doesn't build it because the solution lacks a Build.0 entry for the test project at that platform.
  • README updates documenting panel persistence, unsaved-buffer survival, and the Notepad++-side "two clicks to relaunch" symptom.

Test plan

  • 54 unit tests pass locally with the new CI flow (msbuild Debug|x64 + dotnet test without --no-build)
  • Manual: panel reopens automatically after Notepad++ restart
  • Manual: open files in virtual folders survive restart
  • Manual: unsaved buffers survive restart with N++ session backup on; cleaned up silently with it off
  • Awaiting green CI run on this PR

CI was failing with "test source file ... was not found". Root cause: the
solution maps the test project's Debug|x64 to Debug|Any CPU.ActiveCfg
without a Build.0 entry, so msbuild /p:Platform=x64 doesn't actually build
the test project. The MSBuild step then completes successfully, and the
following 'dotnet test --no-build' step finds nothing to run.

Adding Build.0 lines isn't a good fix because standalone MSBuild can't
resolve Microsoft.NET.Sdk for the SDK-style test csproj without the .NET
SDK on PATH. The CI runner happens to have it via setup-msbuild, but that
creates a local-vs-CI divergence.

Cleanest fix: drop --no-build from the dotnet test step. dotnet test
invokes the SDK to build the test project (and transitively the plugin
project via ProjectReference) before running tests. This mirrors the
local workflow exactly. The preceding msbuild step still validates that
the plugin builds for Debug|x64 specifically.
@JamesShaver JamesShaver merged commit db39e6b into main May 20, 2026
1 check passed
@JamesShaver JamesShaver deleted the v1.0.0-implementation branch May 20, 2026 22:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant