Use Avalonia-generated InitializeComponent

[wieslawsoltes]

PR Summary: Use Avalonia-generated InitializeComponent

Branch

• feat/avalonia-generated-initializecomponent

Goal

Remove explicit AvaloniaXamlLoader.Load(this) usage from Dock views and user controls, move sample projects to Avalonia's generated InitializeComponent path, and keep the solution building cleanly under the generator-based setup.

Why this change

The local Avalonia source confirms that AvaloniaNameGeneratorBehavior=InitializeComponent is the mode that generates both named-part properties and the InitializeComponent implementation for supported view types. That makes handwritten AvaloniaXamlLoader.Load(this) wrappers in view code-behind redundant.

The same review also showed an important distinction for Application:

• StyledElement-based views can rely on the name generator.
• Application loading follows Avalonia's compiler path instead of the name generator path.

Because of that, this PR removes manual loader calls from App.axaml.cs files only where Avalonia can inject the load through the trivial default constructor path, and it refactors the DI sample so it also fits that model.

Scope

• 272 files changed
• 24 sample project files switched to generated InitializeComponent
• 195 sample view code-behind files cleaned up
• 25 sample App.axaml.cs files cleaned up
• 7 test App.axaml.cs files cleaned up
• 19 diagnostics control code-behind files cleaned up
• 1 documentation article updated

What changed

1. Sample projects now use generated InitializeComponent

24 sample projects that previously used AvaloniaNameGeneratorBehavior=OnlyProperties now use AvaloniaNameGeneratorBehavior=InitializeComponent.

This aligns the project setting with the desired runtime/code-behind pattern:

• constructors call InitializeComponent();
• no local private void InitializeComponent() wrapper is needed
• no explicit AvaloniaXamlLoader.Load(this) remains in view/user control/window code-behind

Representative files:

• samples/DockReactiveUISample/DockReactiveUISample.csproj
• samples/DockReactiveUIDiSample/DockReactiveUIDiSample.csproj
• samples/DockXamlSample/DockXamlSample.csproj
• samples/WebViewSample/WebViewSample.csproj

2. Sample views and windows were simplified

195 sample view code-behind files were updated to use the generated implementation directly. In most cases this was a pure deletion of the handwritten loader method. Constructors now stay limited to:

public MainWindow()
{
    InitializeComponent();
}

Representative files:

• samples/DockReactiveUISample/Views/MainWindow.axaml.cs
• samples/DockReactiveUIRoutingSample/Views/DockView.axaml.cs
• samples/DockFigmaSample/Views/WorkspaceView.axaml.cs
• samples/Notepad/Views/MainView.axaml.cs

One small structural cleanup was kept where post-load work already existed:

• samples/DockXamlSample/MainView.axaml.cs

3. Diagnostics controls now follow the same generated path

19 controls in src/Dock.Avalonia.Diagnostics/Controls had local AvaloniaXamlLoader.Load(this) wrappers removed. These controls now match the rest of the codebase and rely on Avalonia's generated initializer.

Representative files:

• src/Dock.Avalonia.Diagnostics/Controls/DockDebugView.axaml.cs
• src/Dock.Avalonia.Diagnostics/Controls/RootDockDebug.axaml.cs
• src/Dock.Avalonia.Diagnostics/Controls/ToolDockDebugView.axaml.cs

4. Sample and test App classes no longer call AvaloniaXamlLoader.Load(this)

The remaining App.axaml.cs occurrences were removed from:

• 25 sample app classes
• 7 test app classes

These classes now rely on Avalonia's compiler-generated application initialization path instead of explicit manual loading.

Representative files:

• samples/DockReactiveUISample/App.axaml.cs
• samples/BrowserTabTheme/App.axaml.cs
• samples/WebViewSample/App.axaml.cs
• tests/Dock.Avalonia.UnitTests/App.axaml.cs

5. DockReactiveUIDiSample startup was refactored

The DI sample previously depended on a custom App construction pattern. That made it the main exception once explicit App loader calls were removed.

The sample was refactored so App can still be created through a trivial constructor and receive dependencies after construction:

• App now exposes init-only properties:
  • ServiceProvider
  • ViewLocator
• Initialize() only inserts the ViewLocator data template when available
• Program.cs no longer registers App as a container singleton
• AppBuilder.Configure(...) now uses a factory that creates App and sets the init properties

Files:

• samples/DockReactiveUIDiSample/App.axaml.cs
• samples/DockReactiveUIDiSample/Program.cs

6. Documentation was updated

The ReactiveUI DI article contained the now-stale constructor-based App pattern and a manual loader call. The article was updated to match the new implementation.

File:

• docfx/articles/dock-reactiveui-di.md

Remaining explicit loader calls

Only intentional service-provider-based theme loads remain:

• src/Dock.Avalonia.Themes.Fluent/DockFluentTheme.axaml.cs
• src/Dock.Avalonia.Themes.Simple/DockSimpleTheme.axaml.cs
• src/Dock.Avalonia.Themes.Browser/Styles/BrowserTabTheme.axaml.cs

These are not Load(this) calls and were left unchanged.

Commit breakdown

1. 997d893b4 refactor(samples): use generated InitializeComponent in sample views
2. f5a848d21 refactor(diagnostics): use generated InitializeComponent
3. d34246ee0 refactor(apps): remove manual App XAML loader calls
4. 740817590 refactor(di): simplify DockReactiveUIDiSample app startup
5. 8af6a15e6 docs: update ReactiveUI DI app initialization

Validation

Search validation

The exact search below returns no source matches outside obj:

rg -n "AvaloniaXamlLoader\\.Load\\(this\\)" . -g '!**/obj/**'

Build validation

dotnet build Dock.slnx

Result: build succeeded.

Known remaining warnings

These warnings were present outside the scope of this migration and were not changed by this PR:

• CS1591 in src/Dock.Controls.Recycling/RecylingDataTemplate.cs
• IL2026 / IL3050 ReactiveUI trim/AOT warnings in several sample projects
• CS0618 in samples/DockCodeOnlySample/Program.cs
• CS0067 in tests/Dock.Avalonia.LeakTests

Review notes

• Future view code-behind should keep to InitializeComponent(); only and should not add local AvaloniaXamlLoader.Load(this) wrappers back.
• Future App refactors should preserve Avalonia's application-loading expectations. If constructor injection is reintroduced, the startup path should be reviewed carefully so App.axaml still loads through Avalonia's compiler path.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8af6a15e6e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ff9ef93bfd

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 184080bc77

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".