From 3b37eff5d3cf87d1d2bce4f4b165358d09d38e11 Mon Sep 17 00:00:00 2001
From: Christoph Wille <christoph.wille@gmail.com>
Date: Sat, 15 Aug 2026 19:29:03 +0200
Subject: [PATCH 1/7] Close every window a headless UI test showed, and let go
 of shared flyouts

The headless test host runs the app without an application lifetime,
so the window-closing step in ResetAppState never had a list to work
from and every MainWindow the suite showed stayed open - and reachable
from the compositor, together with its view-models, assembly tree and
loaded assemblies. Measured at about 13 MB per test, 15 GB over the
suite, enough to page out the CI runner and stall the tests that scan
process module lists.

Closing is not sufficient on its own: Avalonia's Button subscribes to
its flyout's Opened/Closed and only unsubscribes when the Flyout
property changes, and Dock's ToolChromeControl theme hands every tool
pane's chrome button one shared MenuFlyout resource, which therefore
pinned every closed window's visual tree. The flyouts are detached
before the window closes.

Assisted-by: Claude:claude-fable-5:Claude Code
---
 ILSpy.Tests/ResetAppStateAttribute.cs | 47 ++++++++++++++++++++++++---
 1 file changed, 42 insertions(+), 5 deletions(-)

diff --git a/ILSpy.Tests/ResetAppStateAttribute.cs b/ILSpy.Tests/ResetAppStateAttribute.cs
index 8aea605b91..c4d3ebc73f 100644
--- a/ILSpy.Tests/ResetAppStateAttribute.cs
+++ b/ILSpy.Tests/ResetAppStateAttribute.cs
@@ -17,14 +17,16 @@
 // DEALINGS IN THE SOFTWARE.
 
 using System;
+using System.Collections.Generic;
 using System.IO;
 using System.Linq;
 using System.Threading;
 using System.Threading.Tasks;
 
 using Avalonia;
-using Avalonia.Controls.ApplicationLifetimes;
+using Avalonia.Controls;
 using Avalonia.Threading;
+using Avalonia.VisualTree;
 
 using ICSharpCode.ILSpyX.Settings;
 
@@ -100,15 +102,50 @@ public void AfterTest(ITest test)
 		DrainPendingWork();
 
 		// Close any windows the test showed so their view-models (alive and weakly subscribed to
-		// MessageBus) can't react to events raised by later tests, then drain once more.
-		if (Application.Current.ApplicationLifetime is IClassicDesktopStyleApplicationLifetime desktop)
+		// MessageBus) can't react to events raised by later tests, then drain once more. A window
+		// left open also outlives its container: the compositor keeps every open top level
+		// reachable, and with it the view-models, the assembly tree and the loaded assemblies -
+		// about 13 MB per test, which over the suite is what pushed the CI runner into paging.
+		foreach (var window in openWindows.ToArray())
 		{
-			foreach (var window in desktop.Windows.ToArray())
-				window.Close();
+			DetachFlyouts(window);
+			window.Close();
 		}
 		Dispatcher.UIThread.RunJobs();
 	}
 
+	// Avalonia's Button subscribes to its flyout's Opened/Closed events when its template is
+	// applied and unsubscribes only when the Flyout property changes, not when the button leaves
+	// the tree. Dock's ToolChromeControl theme gives every tool pane's chrome button the same
+	// MenuFlyout resource, so that one shared flyout would keep the visual tree of every window
+	// this suite ever showed alive. Clearing the property before the window closes is what
+	// makes the button let go.
+	static void DetachFlyouts(Window window)
+	{
+		foreach (var button in window.GetVisualDescendants().OfType<Button>())
+		{
+			if (button.Flyout != null)
+				button.Flyout = null;
+		}
+	}
+
+	// The headless host runs the app without an application lifetime, so nothing tracks the
+	// windows the tests show. These are the same class handlers ClassicDesktopStyleApplicationLifetime
+	// installs to maintain its Windows list.
+	static readonly List<Window> openWindows = new();
+
+	static ResetAppStateAttribute()
+	{
+		Window.WindowOpenedEvent.AddClassHandler(typeof(Window), (sender, _) => {
+			if (sender is Window window && !openWindows.Contains(window))
+				openWindows.Add(window);
+		});
+		Window.WindowClosedEvent.AddClassHandler(typeof(Window), (sender, _) => {
+			if (sender is Window window)
+				openWindows.Remove(window);
+		});
+	}
+
 	static void DrainPendingWork()
 	{
 		Task quiesce;

From 27f5e2bc693adc2f7ad142417419e05c59b725e2 Mon Sep 17 00:00:00 2001
From: Christoph Wille <christoph.wille@gmail.com>
Date: Sat, 15 Aug 2026 19:29:34 +0200
Subject: [PATCH 2/7] Unsubscribe DebugStepsPaneModel from the static writing
 options on dispose

WritingOptions is process-wide static state, and the pane subscribes to
its PropertyChanged in the constructor. Every composition container
that is built and disposed (the headless UI test suite does that per
test) left its pane behind on that event, and through the pane's
LanguageService the rest of the container's object graph with it.
System.Composition disposes IDisposable shared parts with the
container, which is the moment to let go.

Assisted-by: Claude:claude-fable-5:Claude Code
---
 ILSpy/ViewModels/DebugStepsPaneModel.cs | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/ILSpy/ViewModels/DebugStepsPaneModel.cs b/ILSpy/ViewModels/DebugStepsPaneModel.cs
index 319cf2ec83..41a0ed7db0 100644
--- a/ILSpy/ViewModels/DebugStepsPaneModel.cs
+++ b/ILSpy/ViewModels/DebugStepsPaneModel.cs
@@ -18,6 +18,7 @@
 
 #if DEBUG
 
+using System;
 using System.Collections.Generic;
 using System.ComponentModel;
 using System.Composition;
@@ -52,7 +53,7 @@ namespace ICSharpCode.ILSpy.ViewModels
 	[Export]
 	[ExportToolPane(ContentId = PaneContentId, Alignment = ToolPaneAlignment.Bottom, Order = 1, IsVisibleByDefault = false)]
 	[Shared]
-	public sealed partial class DebugStepsPaneModel : ToolPaneModel
+	public sealed partial class DebugStepsPaneModel : ToolPaneModel, IDisposable
 	{
 		public const string PaneContentId = "DebugSteps";
 
@@ -186,6 +187,21 @@ public DebugStepsPaneModel(LanguageService languageService) : this()
 			TryAttachToCurrentLanguage();
 		}
 
+		/// <summary>
+		/// Called when the composition container that owns this pane is disposed. The writing
+		/// options are process-wide static state, so the subscription taken in the constructor
+		/// would otherwise keep this pane - and through <see cref="languageService"/> the whole
+		/// composition it belongs to - alive for as long as the process runs.
+		/// </summary>
+		public void Dispose()
+		{
+			WritingOptions.PropertyChanged -= OnWritingOptionsChanged;
+			MessageBus<AssemblyTreeSelectionChangedEventArgs>.Subscribers -= OnSelectionChanged;
+			if (languageService != null)
+				languageService.PropertyChanged -= OnLanguageServiceChanged;
+			DetachFromLanguage();
+		}
+
 		void OnLanguageServiceChanged(object? sender, PropertyChangedEventArgs e)
 		{
 			if (e.PropertyName == nameof(LanguageService.CurrentLanguage))

From 1c9c3d9c2acc5847ab52f2db5d66c784316a7338 Mon Sep 17 00:00:00 2001
From: Christoph Wille <christoph.wille@gmail.com>
Date: Sat, 15 Aug 2026 19:30:05 +0200
Subject: [PATCH 3/7] Run the indeterminate progress animations only while
 something is in progress

The search pane's progress bar was permanently indeterminate and merely
hidden when idle, and the decompiler view's bar defaults to
indeterminate mode whether or not a decompilation is running. The
indeterminate indicator is an infinite keyframe animation that keeps
running - and keeps the control's whole visual tree alive through the
render clock - for as long as the pseudo-class is set, hidden or not.
Both bars now go indeterminate only for the duration of the work.

Assisted-by: Claude:claude-fable-5:Claude Code
---
 ILSpy.Tests/Search/SearchProgressTests.cs | 16 ++++++++++++++--
 ILSpy/Search/SearchPane.axaml             |  7 +++++--
 ILSpy/TextView/DecompilerTabPageModel.cs  | 10 ++++++++++
 ILSpy/TextView/DecompilerTextView.axaml   |  2 +-
 4 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/ILSpy.Tests/Search/SearchProgressTests.cs b/ILSpy.Tests/Search/SearchProgressTests.cs
index 664085afaf..7a775e2a64 100644
--- a/ILSpy.Tests/Search/SearchProgressTests.cs
+++ b/ILSpy.Tests/Search/SearchProgressTests.cs
@@ -24,6 +24,7 @@
 using Avalonia.Controls;
 using Avalonia.Headless.NUnit;
 using Avalonia.Media;
+using Avalonia.Threading;
 
 using AwesomeAssertions;
 
@@ -115,7 +116,18 @@ public async Task SearchPane_Hosts_A_Progress_Indicator_Bound_To_IsSearching()
 		var progress = pane.FindControl<ProgressBar>("SearchProgress");
 		((object?)progress).Should().NotBeNull(
 			"the pane must host a progress indicator the user can see while a search runs");
-		progress!.IsIndeterminate.Should().BeTrue(
-			"the indicator runs in indeterminate mode — we don't know the total work up front");
+
+		// Indeterminate mode is tied to the search, not switched on permanently: the indicator
+		// is an infinite animation, and one that ran while idle would keep the render clock
+		// busy for as long as the pane exists.
+		var search = AppComposition.Current.GetExport<SearchPaneModel>();
+		progress!.IsIndeterminate.Should().BeFalse("nothing is running yet");
+		search.IsSearching = true;
+		Dispatcher.UIThread.RunJobs();
+		progress.IsIndeterminate.Should().BeTrue(
+			"the indicator runs in indeterminate mode while a search is in flight - we don't know the total work up front");
+		search.IsSearching = false;
+		Dispatcher.UIThread.RunJobs();
+		progress.IsIndeterminate.Should().BeFalse("the animation stops with the search");
 	}
 }
diff --git a/ILSpy/Search/SearchPane.axaml b/ILSpy/Search/SearchPane.axaml
index 371993e87e..9e9e27099e 100644
--- a/ILSpy/Search/SearchPane.axaml
+++ b/ILSpy/Search/SearchPane.axaml
@@ -49,9 +49,12 @@
 		</Grid>
 		<!-- Indeterminate progress strip: lights up while RunningSearch is in flight. Mirrors
 		     WPF's searchProgressBar; the height is just enough to be noticed without stealing
-		     space from the results list. -->
+		     space from the results list. IsIndeterminate follows the search too, not just
+		     IsVisible: the indeterminate indicator is an infinite animation that keeps running
+		     (and keeps the pane's visual tree alive through the render clock) for as long as
+		     the pseudo-class is set, hidden or not. -->
 		<ProgressBar Grid.Row="1" Name="SearchProgress"
-		             IsIndeterminate="True"
+		             IsIndeterminate="{Binding IsSearching}"
 		             IsVisible="{Binding IsSearching}"
 		             Height="2" Margin="0,0,0,1"
 		             BorderThickness="0"
diff --git a/ILSpy/TextView/DecompilerTabPageModel.cs b/ILSpy/TextView/DecompilerTabPageModel.cs
index 51127f1d02..565b9b0b45 100644
--- a/ILSpy/TextView/DecompilerTabPageModel.cs
+++ b/ILSpy/TextView/DecompilerTabPageModel.cs
@@ -103,6 +103,7 @@ partial void OnTextChanged(string? oldValue, string newValue)
 		/// in the header while this is set.
 		/// </summary>
 		[ObservableProperty]
+		[NotifyPropertyChangedFor(nameof(ProgressBarIsIndeterminate))]
 		private bool isDecompiling;
 
 		/// <summary>
@@ -120,8 +121,17 @@ partial void OnTextChanged(string? oldValue, string newValue)
 		/// off so the bar becomes determinate; an in-place decompile leaves it on.
 		/// </summary>
 		[ObservableProperty]
+		[NotifyPropertyChangedFor(nameof(ProgressBarIsIndeterminate))]
 		private bool progressIsIndeterminate = true;
 
+		/// <summary>
+		/// What the progress bar binds its IsIndeterminate to: indeterminate mode, but only while a
+		/// decompilation is running. The indeterminate indicator is an infinite animation, and it
+		/// keeps running - and keeps the view alive through the render clock - for as long as the
+		/// pseudo-class is set, whether the bar is visible or not.
+		/// </summary>
+		public bool ProgressBarIsIndeterminate => IsDecompiling && ProgressIsIndeterminate;
+
 		/// <summary>Total units to process (the project's file count) for the determinate bar.</summary>
 		[ObservableProperty]
 		private double progressMaximum;
diff --git a/ILSpy/TextView/DecompilerTextView.axaml b/ILSpy/TextView/DecompilerTextView.axaml
index 2e08f54c3b..7cd8fc60cb 100644
--- a/ILSpy/TextView/DecompilerTextView.axaml
+++ b/ILSpy/TextView/DecompilerTextView.axaml
@@ -40,7 +40,7 @@
 					           Text="{Binding ProgressTitle}" />
 					<ProgressBar Name="ProgressBar"
 					             x:CompileBindings="False"
-					             IsIndeterminate="{Binding ProgressIsIndeterminate}"
+					             IsIndeterminate="{Binding ProgressBarIsIndeterminate}"
 					             Minimum="0"
 					             Maximum="{Binding ProgressMaximum}"
 					             Value="{Binding ProgressValue}"

From 84a7839a298fe359c4cf37a6480e7886f9225f19 Mon Sep 17 00:00:00 2001
From: Christoph Wille <christoph.wille@gmail.com>
Date: Sun, 16 Aug 2026 09:52:21 +0200
Subject: [PATCH 4/7] Withdraw a window's Help items from the macOS app menu,
 and add a retention canary

The app-level NativeMenu declared in App.axaml lives as long as the
process, while every MainWindow builds its own Help items over its own
command instances (AboutCommand reaches the DockWorkspace and, through
it, the whole app graph). PromoteHelpToMacAppMenu inserted each window's
items without taking the previous window's out and nothing removed them
on close, so on macOS the headless suite kept every test's app graph
alive - the same 13 MB per test as the anchors fixed earlier on this
branch, and the reason the memory win did not reproduce on macOS
(retained gen2 still climbing to ~4 GB there while a Windows run peaks
at 0.7 GB). Forcing the macOS path on Windows reproduces the growth
(14.3 GB peak private bytes over the suite); withdrawn, it is 0.7 GB.

Three smaller anchors of the same kind, found while making the canary
below hold in the full suite: RichNodeText and AnalyzerTreeNode cached
the first container's exports in statics, which subscribed later
windows to a stale settings object, handed later analyzers the first
test's assembly list, and kept the first app graph reachable for the
run; and a search still in flight when its container went away kept its
drain timer and IsSearching - hence the pane's indeterminate progress
animation on the render clock - alive, retaining every window a search
test closed mid-run (about 30 of them, ~400 MB).

The canary test closes a MainWindow the way the per-test teardown does
and waits for it to become collectable. It fails on any single anchor
being restored (checked by leaving DetachFlyouts out), which is the
regression guard the individual anchor fixes lacked; the teardown body
is exposed as TearDownTestState so the test performs exactly what
AfterTest does.

Assisted-by: Claude:claude-fable-5:Claude Code
---
 ILSpy.Tests/MainWindow/MainMenuTests.cs | 32 +++++++++
 ILSpy.Tests/ResetAppStateAttribute.cs   |  7 ++
 ILSpy.Tests/TeardownRetentionTests.cs   | 91 +++++++++++++++++++++++++
 ILSpy/Analyzers/AnalyzerTreeNode.cs     | 13 ++--
 ILSpy/Controls/TreeView/RichNodeText.cs |  6 +-
 ILSpy/Search/SearchPaneModel.cs         | 12 +++-
 ILSpy/Views/MainMenu.axaml.cs           | 25 ++++++-
 7 files changed, 174 insertions(+), 12 deletions(-)
 create mode 100644 ILSpy.Tests/TeardownRetentionTests.cs

diff --git a/ILSpy.Tests/MainWindow/MainMenuTests.cs b/ILSpy.Tests/MainWindow/MainMenuTests.cs
index 0095168852..50ce4f43cd 100644
--- a/ILSpy.Tests/MainWindow/MainMenuTests.cs
+++ b/ILSpy.Tests/MainWindow/MainMenuTests.cs
@@ -95,6 +95,38 @@ public void File_Open_Carries_The_Ctrl_O_Gesture()
 		openItem.Gesture!.Should().Be(expected);
 	}
 
+	// The app-level NativeMenu (App.axaml) is process-wide, while every MainWindow builds
+	// its own Help items over its own command instances. On macOS each new window promotes
+	// them into that app menu; the ones an earlier window promoted must be replaced, not
+	// kept - otherwise the app menu pins every earlier window's command graph (and, in the
+	// headless suite, every test's app graph) for the life of the process.
+	[AvaloniaTest]
+	public void Promoting_Help_Again_Replaces_The_Items_An_Earlier_Window_Promoted()
+	{
+		var appMenu = NativeMenu.GetMenu(Application.Current!);
+		appMenu.Should().NotBeNull("App.axaml declares the NativeMenu the Help items move into");
+
+		static (NativeMenu Root, System.Collections.Generic.Dictionary<string, NativeMenuItem> ByTag) WindowMenuWithHelp(string header)
+		{
+			var help = new NativeMenuItem { Header = "_Help", Menu = new NativeMenu() };
+			help.Menu.Items.Add(new NativeMenuItem { Header = header });
+			var root = new NativeMenu();
+			root.Items.Add(help);
+			return (root, new System.Collections.Generic.Dictionary<string, NativeMenuItem>(StringComparer.Ordinal) { ["_Help"] = help });
+		}
+
+		var first = WindowMenuWithHelp("About (first window)");
+		MainMenu.PromoteHelpToMacAppMenu(first.Root, first.ByTag);
+		var afterFirst = appMenu!.Items.Count;
+		var second = WindowMenuWithHelp("About (second window)");
+		MainMenu.PromoteHelpToMacAppMenu(second.Root, second.ByTag);
+
+		appMenu.Items.Count.Should().Be(afterFirst, "the second window's Help items replace the first window's");
+		appMenu.Items.OfType<NativeMenuItem>().Select(i => i.Header)
+			.Should().Contain("About (second window)")
+			.And.NotContain("About (first window)");
+	}
+
 	// NativeMenuItem.Gesture is display-only when NativeMenuBar renders the menu inline
 	// (the managed fallback binds it to MenuItem.InputGesture, which never handles input),
 	// so every menu gesture must also be registered as a window-level KeyBinding or the
diff --git a/ILSpy.Tests/ResetAppStateAttribute.cs b/ILSpy.Tests/ResetAppStateAttribute.cs
index c4d3ebc73f..de957195ae 100644
--- a/ILSpy.Tests/ResetAppStateAttribute.cs
+++ b/ILSpy.Tests/ResetAppStateAttribute.cs
@@ -94,6 +94,13 @@ public void AfterTest(ITest test)
 		if (Application.Current == null || !Dispatcher.UIThread.CheckAccess())
 			return;
 
+		TearDownTestState();
+	}
+
+	// Everything the per-test teardown does on the dispatcher thread; exposed so a test can
+	// perform the teardown itself and check what it leaves behind (see TeardownRetentionTests).
+	internal static void TearDownTestState()
+	{
 		// Drive background work to quiescence BEFORE the next test rebuilds the composition. A test
 		// that triggers a decompile spawns a Task.Run plus dispatcher continuations and rarely awaits
 		// them to completion; left running, that continuation lands during the next test and reads
diff --git a/ILSpy.Tests/TeardownRetentionTests.cs b/ILSpy.Tests/TeardownRetentionTests.cs
new file mode 100644
index 0000000000..d273afb5ce
--- /dev/null
+++ b/ILSpy.Tests/TeardownRetentionTests.cs
@@ -0,0 +1,91 @@
+// Copyright (c) 2026 Christoph Wille
+//
+// Permission is hereby granted, free of charge, to any person obtaining a copy of this
+// software and associated documentation files (the "Software"), to deal in the Software
+// without restriction, including without limitation the rights to use, copy, modify, merge,
+// publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons
+// to whom the Software is furnished to do so, subject to the following conditions:
+//
+// The above copyright notice and this permission notice shall be included in all copies or
+// substantial portions of the Software.
+//
+// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
+// INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
+// PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE
+// FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+// OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+// DEALINGS IN THE SOFTWARE.
+
+using System;
+using System.Linq;
+using System.Runtime.CompilerServices;
+using System.Threading.Tasks;
+
+using Avalonia.Headless;
+using Avalonia.Headless.NUnit;
+using Avalonia.Threading;
+
+using ICSharpCode.ILSpy.AppEnv;
+using ICSharpCode.ILSpy.AssemblyTree;
+using ICSharpCode.ILSpy.Views;
+
+using NUnit.Framework;
+
+namespace ICSharpCode.ILSpy.Tests;
+
+// Most tests in this suite show a MainWindow, and the per-test teardown closes it and rebuilds
+// the composition container. Anything that still reaches a closed window - a static event, a
+// shared XAML resource with a subscriber, an animation on the render clock, the app-level menu -
+// keeps that test's whole app graph (view-models, tree, loaded assemblies; about 13 MB) alive
+// for the rest of the run, and over the suite that is enough to push a 16 GB CI runner into
+// paging. Rather than asserting the absence of each known anchor, this test performs the
+// teardown itself and checks that the window is actually collectable afterwards.
+[TestFixture]
+public class TeardownRetentionTests
+{
+	[AvaloniaTest]
+	public async Task A_Main_Window_Closed_By_The_Teardown_Is_Collectable()
+	{
+		var window = ShowMainWindow();
+		// Let the assembly loads the window started run to completion first: each one posts its
+		// completion to the dispatcher, and one posted after the teardown would hold the tree (and
+		// with it the window) until the next test pumps it - a false positive, not retention.
+		await Waiters.WaitForAsync(static () => AllAssembliesLoaded());
+
+		ResetAppStateAttribute.TearDownTestState();
+		// What the next test's BeforeTest does: the fresh container drops the [Shared] MainWindow.
+		AppComposition.CreateContainer();
+
+		// The closed window's final composition batch (its target's disposal) references it until
+		// the compositor has committed and rendered it, and commits are throttled behind the
+		// previous batch's completion, which comes back through the thread pool - so keep pumping
+		// the dispatcher (and the headless render loop, which only ticks on request) while polling.
+		await Waiters.WaitForAsync(() => IsCollected(window), TimeSpan.FromSeconds(10),
+			"the closed MainWindow to become unreachable once its container is gone");
+	}
+
+	static bool IsCollected(WeakReference window)
+	{
+		AvaloniaHeadlessPlatform.ForceRenderTimerTick();
+		GC.Collect();
+		GC.WaitForPendingFinalizers();
+		GC.Collect();
+		return !window.IsAlive;
+	}
+
+	static bool AllAssembliesLoaded()
+	{
+		var assemblies = AppComposition.Current.GetExport<AssemblyTreeModel>().AssemblyList?.GetAssemblies();
+		return assemblies is { Length: > 0 } && assemblies.All(a => a.IsLoaded);
+	}
+
+	// The window must not be referenced from this test's own frame while the GC runs.
+	[MethodImpl(MethodImplOptions.NoInlining)]
+	static WeakReference ShowMainWindow()
+	{
+		var window = AppComposition.Current.GetExport<MainWindow>();
+		window.Show();
+		Dispatcher.UIThread.RunJobs();
+		return new WeakReference(window);
+	}
+}
diff --git a/ILSpy/Analyzers/AnalyzerTreeNode.cs b/ILSpy/Analyzers/AnalyzerTreeNode.cs
index 7c30fb6a21..c6093196d6 100644
--- a/ILSpy/Analyzers/AnalyzerTreeNode.cs
+++ b/ILSpy/Analyzers/AnalyzerTreeNode.cs
@@ -37,23 +37,24 @@ namespace ICSharpCode.ILSpy.Analyzers
 	/// </summary>
 	public abstract class AnalyzerTreeNode : SharpTreeNode
 	{
-		static LanguageService? cachedLanguageService;
-		static AnalyzerRegistry? cachedRegistry;
-		static AssemblyTreeModel? cachedAssemblyTreeModel;
+		// The exports below are resolved on every access rather than cached in statics: the
+		// composition root is rebuilt per test in the headless suite, and a static cache would
+		// hand later tests the first test's language service and assembly list and keep that
+		// first app graph reachable for the run. A warm GetExport is a dictionary lookup.
 
 		/// <summary>
 		/// The active language used to format entity text. Resolved lazily through the
 		/// composition host so design-time previews (no MEF) don't NRE during XAML reload.
 		/// </summary>
 		protected static Languages.Language Language
-			=> (cachedLanguageService ??= AppComposition.Current.GetExport<LanguageService>()).CurrentLanguage;
+			=> AppComposition.Current.GetExport<LanguageService>().CurrentLanguage;
 
 		/// <summary>
 		/// The active <see cref="AssemblyList"/> backing the assembly tree. Search nodes pass
 		/// it into <c>AnalyzerContext</c> so each analyser can iterate the loaded modules.
 		/// </summary>
 		protected static AssemblyList? CurrentAssemblyList
-			=> (cachedAssemblyTreeModel ??= AppComposition.Current.GetExport<AssemblyTreeModel>()).AssemblyList;
+			=> AppComposition.Current.GetExport<AssemblyTreeModel>().AssemblyList;
 
 		/// <summary>
 		/// All MEF-registered <see cref="IAnalyzer"/> exports, ordered by their declared
@@ -63,7 +64,7 @@ protected static AssemblyList? CurrentAssemblyList
 		/// <see cref="IAnalyzer.Show"/> returns true for the wrapped entity.
 		/// </summary>
 		public static IReadOnlyList<ExportFactory<IAnalyzer, AnalyzerMetadata>> Analyzers
-			=> (cachedRegistry ??= AppComposition.Current.GetExport<AnalyzerRegistry>()).Analyzers;
+			=> AppComposition.Current.GetExport<AnalyzerRegistry>().Analyzers;
 
 		public override bool CanDelete() => Parent is { IsRoot: true };
 
diff --git a/ILSpy/Controls/TreeView/RichNodeText.cs b/ILSpy/Controls/TreeView/RichNodeText.cs
index 83bfd75d77..26cab85c9e 100644
--- a/ILSpy/Controls/TreeView/RichNodeText.cs
+++ b/ILSpy/Controls/TreeView/RichNodeText.cs
@@ -58,9 +58,11 @@ public static class RichNodeText
 		static readonly AttachedProperty<bool> CleanupHookedProperty =
 			AvaloniaProperty.RegisterAttached<TextBlock, bool>("CleanupHooked", typeof(RichNodeText));
 
-		static LanguageSettings? languageSettings;
+		// Resolved on every call rather than cached: the composition root is rebuilt per test in the
+		// headless suite, and a static cache would both subscribe later windows to a stale settings
+		// object and keep the first window's tree reachable through it. A warm export lookup is cheap.
 		static LanguageSettings? GetLanguageSettings()
-			=> languageSettings ??= AppComposition.TryGetExport<SettingsService>()?.SessionSettings.LanguageSettings;
+			=> AppComposition.TryGetExport<SettingsService>()?.SessionSettings.LanguageSettings;
 
 		static RichNodeText()
 		{
diff --git a/ILSpy/Search/SearchPaneModel.cs b/ILSpy/Search/SearchPaneModel.cs
index 56aca21310..5e96f5d30a 100644
--- a/ILSpy/Search/SearchPaneModel.cs
+++ b/ILSpy/Search/SearchPaneModel.cs
@@ -53,7 +53,7 @@ public sealed class SearchModeEntry
 	[Export]
 	[ExportToolPane(ContentId = PaneContentId, Alignment = ToolPaneAlignment.Top, Order = 0, IsVisibleByDefault = false)]
 	[Shared]
-	public partial class SearchPaneModel : ToolPaneModel
+	public sealed partial class SearchPaneModel : ToolPaneModel, IDisposable
 	{
 		public const string PaneContentId = "Search";
 
@@ -265,6 +265,16 @@ void RestartSearch()
 			run.Start();
 		}
 
+		// The composition container is the only owner and disposes this model with itself. A search
+		// still in flight at that point owns a dispatcher timer and keeps IsSearching (and with it the
+		// pane's indeterminate progress animation) on; both would otherwise outlive the container.
+		public void Dispose()
+		{
+			currentSearch?.Cancel();
+			currentSearch = null;
+			IsSearching = false;
+		}
+
 		void OnRunCompleted(RunningSearch sender)
 		{
 			// Ignore late completions from cancelled runs — those are noise.
diff --git a/ILSpy/Views/MainMenu.axaml.cs b/ILSpy/Views/MainMenu.axaml.cs
index 1c6786c0b9..68aeca5598 100644
--- a/ILSpy/Views/MainMenu.axaml.cs
+++ b/ILSpy/Views/MainMenu.axaml.cs
@@ -74,12 +74,16 @@ public static void Attach(Window window)
 		{
 			TranslateGesturesForMacOS(menu);
 			PromoteHelpToMacAppMenu(menu, topLevelByTag);
+			window.Closed += (_, _) => WithdrawPromotedHelpItems();
 		}
 
 		RegisterGestureKeyBindings(window, menu);
 		NativeMenu.SetMenu(window, menu);
 	}
 
+	// The Help items currently promoted into the app-level NativeMenu (see PromoteHelpToMacAppMenu).
+	static readonly List<NativeMenuItemBase> promotedHelpItems = new();
+
 	// NativeMenuItem.Gesture is display-only when NativeMenuBar renders the menu inline:
 	// the managed fallback binds it to MenuItem.InputGesture, which never handles input.
 	// So each gesture is registered as a window-level KeyBinding too - that is what makes
@@ -121,25 +125,40 @@ static void RegisterGestureKeyBindings(Window window, NativeMenu menu)
 	// the exporter subscribes to that instance's Items, so inserting fires a re-export.
 	// Items go at the top, above the Services / Hide / Quit block the exporter appended.
 	// We then remove _Help from the window menu so the items don't appear in both places.
-	static void PromoteHelpToMacAppMenu(NativeMenu rootMenu, Dictionary<string, NativeMenuItem> topLevelByTag)
+	// The app menu outlives any one window, and each window's Help items are built over
+	// that window's own command instances, so the items an earlier window promoted are
+	// taken out first (and again when the window closes); leaving them in would keep
+	// that window's command graph, and everything those commands reach, alive for the
+	// life of the process.
+	internal static void PromoteHelpToMacAppMenu(NativeMenu rootMenu, Dictionary<string, NativeMenuItem> topLevelByTag)
 	{
-		if (!topLevelByTag.TryGetValue("_Help", out var helpItem) || helpItem.Menu is null)
-			return;
+		WithdrawPromotedHelpItems();
 		if (Application.Current is null)
 			return;
 		var appMenu = NativeMenu.GetMenu(Application.Current);
 		if (appMenu is null)
 			return;
+		if (!topLevelByTag.TryGetValue("_Help", out var helpItem) || helpItem.Menu is null)
+			return;
 		var index = 0;
 		foreach (var item in helpItem.Menu.Items.ToArray())
 		{
 			helpItem.Menu.Items.Remove(item);
 			appMenu.Items.Insert(index++, item);
+			promotedHelpItems.Add(item);
 		}
 		rootMenu.Items.Remove(helpItem);
 		topLevelByTag.Remove("_Help");
 	}
 
+	static void WithdrawPromotedHelpItems()
+	{
+		var appMenu = Application.Current is null ? null : NativeMenu.GetMenu(Application.Current);
+		foreach (var item in promotedHelpItems)
+			appMenu?.Items.Remove(item);
+		promotedHelpItems.Clear();
+	}
+
 	static bool TryGetExports(
 		out SettingsService settings,
 		out MainMenuCommandRegistry registry,

From d5636e318ff45bc7233c5e117831db5b21e39afe Mon Sep 17 00:00:00 2001
From: Christoph Wille <christoph.wille@gmail.com>
Date: Sun, 16 Aug 2026 09:52:45 +0200
Subject: [PATCH 5/7] Assert the search pane's DataContext before checking the
 progress binding

ProgressBar.IsIndeterminate defaults to false, so the "nothing is running
yet" assertion would also pass against a pane whose DataContext is not
the resolved SearchPaneModel, and the failure would only surface one
line later, blamed on the binding direction rather than on the missing
DataContext.

Assisted-by: Claude:claude-fable-5:Claude Code
---
 ILSpy.Tests/Search/SearchProgressTests.cs | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ILSpy.Tests/Search/SearchProgressTests.cs b/ILSpy.Tests/Search/SearchProgressTests.cs
index 7a775e2a64..71c69ff681 100644
--- a/ILSpy.Tests/Search/SearchProgressTests.cs
+++ b/ILSpy.Tests/Search/SearchProgressTests.cs
@@ -121,6 +121,7 @@ public async Task SearchPane_Hosts_A_Progress_Indicator_Bound_To_IsSearching()
 		// is an infinite animation, and one that ran while idle would keep the render clock
 		// busy for as long as the pane exists.
 		var search = AppComposition.Current.GetExport<SearchPaneModel>();
+		pane.DataContext.Should().BeSameAs(search, "the indicator binds to the pane's own model; anything else makes the assertions below meaningless");
 		progress!.IsIndeterminate.Should().BeFalse("nothing is running yet");
 		search.IsSearching = true;
 		Dispatcher.UIThread.RunJobs();

From d4212b19656342c824f727f3a55ebe8404345574 Mon Sep 17 00:00:00 2001
From: Christoph Wille <christoph.wille@gmail.com>
Date: Sun, 16 Aug 2026 15:11:34 +0200
Subject: [PATCH 6/7] Withdraw only the Help items the closing window itself
 promoted

The app-level NativeMenu is process-wide, so the withdrawal a window does
on Closed has to name the items that window put there. Withdrawing
"whatever is promoted right now" is correct only while one window exists
at a time: with two, closing the older one takes the newer one's About /
Check for Updates out of the macOS app menu, and nothing ever puts them
back. Not reachable today - MainWindow is [Shared] and Attach runs from
its ctor - but the failure mode is silent and permanent, and carrying the
list costs nothing. Removing an item that is already gone is a no-op, so
a superseded window's Closed stays harmless.

The promotion tests also have to leave the app menu as they found it:
it is declared on Application and outlives the test, it is not gated on
macOS, and on Windows and Linux nothing re-promotes over the leftovers.

Assisted-by: Claude:claude-opus-5:Claude Code
---
 ILSpy.Tests/MainWindow/MainMenuTests.cs | 76 ++++++++++++++++++++-----
 ILSpy/Views/MainMenu.axaml.cs           | 44 ++++++++------
 2 files changed, 87 insertions(+), 33 deletions(-)

diff --git a/ILSpy.Tests/MainWindow/MainMenuTests.cs b/ILSpy.Tests/MainWindow/MainMenuTests.cs
index 50ce4f43cd..b770a8e9fd 100644
--- a/ILSpy.Tests/MainWindow/MainMenuTests.cs
+++ b/ILSpy.Tests/MainWindow/MainMenuTests.cs
@@ -17,6 +17,7 @@
 // DEALINGS IN THE SOFTWARE.
 
 using System;
+using System.Collections.Generic;
 using System.Linq;
 
 using Avalonia;
@@ -106,25 +107,70 @@ public void Promoting_Help_Again_Replaces_The_Items_An_Earlier_Window_Promoted()
 		var appMenu = NativeMenu.GetMenu(Application.Current!);
 		appMenu.Should().NotBeNull("App.axaml declares the NativeMenu the Help items move into");
 
-		static (NativeMenu Root, System.Collections.Generic.Dictionary<string, NativeMenuItem> ByTag) WindowMenuWithHelp(string header)
+		MainMenu.PromoteHelpToMacAppMenu(
+			WindowMenuWithHelpItems("About (first window)", out var firstByTag), firstByTag);
+		var afterFirst = appMenu!.Items.Count;
+		var promoted = MainMenu.PromoteHelpToMacAppMenu(
+			WindowMenuWithHelpItems("About (second window)", out var secondByTag), secondByTag);
+		try
+		{
+			appMenu.Items.Count.Should().Be(afterFirst, "the second window's Help items replace the first window's");
+			appMenu.Items.OfType<NativeMenuItem>().Select(i => i.Header)
+				.Should().Contain("About (second window)")
+				.And.NotContain("About (first window)");
+		}
+		finally
 		{
-			var help = new NativeMenuItem { Header = "_Help", Menu = new NativeMenu() };
-			help.Menu.Items.Add(new NativeMenuItem { Header = header });
-			var root = new NativeMenu();
-			root.Items.Add(help);
-			return (root, new System.Collections.Generic.Dictionary<string, NativeMenuItem>(StringComparer.Ordinal) { ["_Help"] = help });
+			RestoreAppMenu(appMenu, promoted);
 		}
+	}
 
-		var first = WindowMenuWithHelp("About (first window)");
-		MainMenu.PromoteHelpToMacAppMenu(first.Root, first.ByTag);
-		var afterFirst = appMenu!.Items.Count;
-		var second = WindowMenuWithHelp("About (second window)");
-		MainMenu.PromoteHelpToMacAppMenu(second.Root, second.ByTag);
+	// The Help items a window promotes are withdrawn when it closes, but only that window's own:
+	// a window closing after a second one has promoted its items must leave those in the app menu,
+	// or macOS shows an app menu with no About / Check for Updates while the second window is still
+	// on screen and nothing ever puts them back.
+	[AvaloniaTest]
+	public void Closing_An_Earlier_Window_Leaves_A_Later_Window_Help_Items_In_Place()
+	{
+		var appMenu = NativeMenu.GetMenu(Application.Current!);
+		appMenu.Should().NotBeNull("App.axaml declares the NativeMenu the Help items move into");
+
+		var first = MainMenu.PromoteHelpToMacAppMenu(
+			WindowMenuWithHelpItems("About (first window)", out var firstByTag), firstByTag);
+		var second = MainMenu.PromoteHelpToMacAppMenu(
+			WindowMenuWithHelpItems("About (second window)", out var secondByTag), secondByTag);
+		try
+		{
+			// What the first window's Closed handler does, now that the second window has promoted.
+			MainMenu.WithdrawHelpItems(first);
 
-		appMenu.Items.Count.Should().Be(afterFirst, "the second window's Help items replace the first window's");
-		appMenu.Items.OfType<NativeMenuItem>().Select(i => i.Header)
-			.Should().Contain("About (second window)")
-			.And.NotContain("About (first window)");
+			appMenu!.Items.OfType<NativeMenuItem>().Select(i => i.Header)
+				.Should().Contain("About (second window)",
+					"the still-open window's Help items must survive an earlier window closing");
+		}
+		finally
+		{
+			RestoreAppMenu(appMenu!, second);
+		}
+	}
+
+	// The app menu is declared on Application and outlives every test, so a test that promotes
+	// placeholder items into it has to take them back out; otherwise a later test reading it
+	// (see MainMenu_top_level_items_are_File_View_Window_in_order) sees this test's leftovers.
+	static void RestoreAppMenu(NativeMenu appMenu, List<NativeMenuItemBase> promoted)
+	{
+		foreach (var item in promoted)
+			appMenu.Items.Remove(item);
+	}
+
+	static NativeMenu WindowMenuWithHelpItems(string header, out Dictionary<string, NativeMenuItem> byTag)
+	{
+		var help = new NativeMenuItem { Header = "_Help", Menu = new NativeMenu() };
+		help.Menu.Items.Add(new NativeMenuItem { Header = header });
+		var root = new NativeMenu();
+		root.Items.Add(help);
+		byTag = new Dictionary<string, NativeMenuItem>(StringComparer.Ordinal) { ["_Help"] = help };
+		return root;
 	}
 
 	// NativeMenuItem.Gesture is display-only when NativeMenuBar renders the menu inline
diff --git a/ILSpy/Views/MainMenu.axaml.cs b/ILSpy/Views/MainMenu.axaml.cs
index 68aeca5598..710d347009 100644
--- a/ILSpy/Views/MainMenu.axaml.cs
+++ b/ILSpy/Views/MainMenu.axaml.cs
@@ -73,16 +73,16 @@ public static void Attach(Window window)
 		if (OperatingSystem.IsMacOS())
 		{
 			TranslateGesturesForMacOS(menu);
-			PromoteHelpToMacAppMenu(menu, topLevelByTag);
-			window.Closed += (_, _) => WithdrawPromotedHelpItems();
+			var promoted = PromoteHelpToMacAppMenu(menu, topLevelByTag);
+			window.Closed += (_, _) => WithdrawHelpItems(promoted);
 		}
 
 		RegisterGestureKeyBindings(window, menu);
 		NativeMenu.SetMenu(window, menu);
 	}
 
-	// The Help items currently promoted into the app-level NativeMenu (see PromoteHelpToMacAppMenu).
-	static readonly List<NativeMenuItemBase> promotedHelpItems = new();
+	// The Help items the most recent PromoteHelpToMacAppMenu put into the app-level NativeMenu.
+	static List<NativeMenuItemBase> promotedHelpItems = new();
 
 	// NativeMenuItem.Gesture is display-only when NativeMenuBar renders the menu inline:
 	// the managed fallback binds it to MenuItem.InputGesture, which never handles input.
@@ -125,38 +125,46 @@ static void RegisterGestureKeyBindings(Window window, NativeMenu menu)
 	// the exporter subscribes to that instance's Items, so inserting fires a re-export.
 	// Items go at the top, above the Services / Hide / Quit block the exporter appended.
 	// We then remove _Help from the window menu so the items don't appear in both places.
-	// The app menu outlives any one window, and each window's Help items are built over
-	// that window's own command instances, so the items an earlier window promoted are
-	// taken out first (and again when the window closes); leaving them in would keep
-	// that window's command graph, and everything those commands reach, alive for the
-	// life of the process.
-	internal static void PromoteHelpToMacAppMenu(NativeMenu rootMenu, Dictionary<string, NativeMenuItem> topLevelByTag)
+	// The app menu outlives any one window, and each window's Help items are built over that
+	// window's own command instances, so the items an earlier window promoted are taken out
+	// first, and each window takes its own back out when it closes; leaving them in would keep
+	// that window's command graph, and everything those commands reach, alive for the life of
+	// the process. The returned list is what that window has to withdraw.
+	internal static List<NativeMenuItemBase> PromoteHelpToMacAppMenu(NativeMenu rootMenu, Dictionary<string, NativeMenuItem> topLevelByTag)
 	{
-		WithdrawPromotedHelpItems();
+		WithdrawHelpItems(promotedHelpItems);
+		var promoted = new List<NativeMenuItemBase>();
 		if (Application.Current is null)
-			return;
+			return promoted;
 		var appMenu = NativeMenu.GetMenu(Application.Current);
 		if (appMenu is null)
-			return;
+			return promoted;
 		if (!topLevelByTag.TryGetValue("_Help", out var helpItem) || helpItem.Menu is null)
-			return;
+			return promoted;
 		var index = 0;
 		foreach (var item in helpItem.Menu.Items.ToArray())
 		{
 			helpItem.Menu.Items.Remove(item);
 			appMenu.Items.Insert(index++, item);
-			promotedHelpItems.Add(item);
+			promoted.Add(item);
 		}
 		rootMenu.Items.Remove(helpItem);
 		topLevelByTag.Remove("_Help");
+		promotedHelpItems = promoted;
+		return promoted;
 	}
 
-	static void WithdrawPromotedHelpItems()
+	// Takes exactly the listed items back out of the app-level NativeMenu -- not "whatever is
+	// promoted right now". A window that closes after a later window promoted its own Help items
+	// must leave those in place, or the app menu ends up with no About / Check for Updates while
+	// that later window is still on screen. Removing an item that is no longer there is a no-op,
+	// so withdrawing a superseded window's list is harmless.
+	internal static void WithdrawHelpItems(List<NativeMenuItemBase> items)
 	{
 		var appMenu = Application.Current is null ? null : NativeMenu.GetMenu(Application.Current);
-		foreach (var item in promotedHelpItems)
+		foreach (var item in items)
 			appMenu?.Items.Remove(item);
-		promotedHelpItems.Clear();
+		items.Clear();
 	}
 
 	static bool TryGetExports(

From ba084e82f7030dbeda1f599b33b1c1c9a8d58413 Mon Sep 17 00:00:00 2001
From: Christoph Wille <christoph.wille@gmail.com>
Date: Tue, 18 Aug 2026 16:38:03 +0200
Subject: [PATCH 7/7] Describe how AnalyzerTreeNode resolves the analyzer
 registry

The registry's summary still described the static accessor as resolving
it once, which stopped being true when the accessors began going through
the current composition host on every access.

Assisted-by: Claude:claude-fable-5:Claude Code
---
 ILSpy/Analyzers/AnalyzerRegistry.cs | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ILSpy/Analyzers/AnalyzerRegistry.cs b/ILSpy/Analyzers/AnalyzerRegistry.cs
index 57bc377a62..e27cc438fe 100644
--- a/ILSpy/Analyzers/AnalyzerRegistry.cs
+++ b/ILSpy/Analyzers/AnalyzerRegistry.cs
@@ -29,7 +29,8 @@ namespace ICSharpCode.ILSpy.Analyzers
 	/// only resolves <c>[ImportMany]</c> with metadata through constructor injection, so this
 	/// registry is the single place that pulls the factories out of the composition host. Each
 	/// <see cref="AnalyzerEntityTreeNode"/> reads <see cref="Analyzers"/> through the static
-	/// accessor on <see cref="AnalyzerTreeNode"/>, which in turn resolves this registry once.
+	/// accessor on <see cref="AnalyzerTreeNode"/>, which resolves this shared registry from the
+	/// current composition host on each access.
 	/// </summary>
 	[Export]
 	[Shared]