Files
LanMountainDesktop/docs/PLUGIN_SDK_V5_MIGRATION.md
lincube 93d6d93815 Migrate to Avalonia 12 and Plugin SDK v5
Upgrade project to the Avalonia 12 baseline and Plugin SDK v5: centralize Avalonia packages, remove legacy WebView.Avalonia usage (use NativeWebView/WebView2 EnvironmentRequested), and update Fluent/Material icon/package usages. Bump multiple package/project versions to 5.0.0 and Avalonia 12.0.1, update plugin template and README/docs to SDK v5, and add PLUGIN_SDK_V5_MIGRATION.md.

Also fix runtime/behavior bugs: make DataLocationResolver use a fixed bootstrap launcher data path and avoid recursive ResolveDataRoot; add legacy-state handling and extraction in OobeStateService; and update component settings tests to reflect migrated storage (DB/backup) and reset cache for test reloads. Various csproj, tests, and docs updated to reflect the migration and ensure build/test compatibility.
2026-04-29 10:16:25 +08:00

1.3 KiB

Plugin SDK v5 Migration Guide

Plugin SDK v5 is the Avalonia 12 compatibility baseline for LanMountainDesktop plugins.

What Changed

  • Rebuild plugins against LanMountainDesktop.PluginSdk 5.0.0.
  • Set plugin.json apiVersion to 5.0.0.
  • Target net10.0 and use Avalonia 12.0.1 compatible UI dependencies.
  • Use FluentAvaloniaUI 3.0.0-preview1 and FluentIcons.Avalonia 2.1.325 when a plugin directly references those packages.

Compatibility

SDK v5 is a binary breaking change because the SDK exposes Avalonia UI types such as Control, UserControl, and SettingsPageBase. Plugins built for SDK v4 must be rebuilt and republished for SDK v5.

The host does not provide an Avalonia 11 / Avalonia 12 dual UI stack. The public extension entry points remain the same: custom settings pages still derive from SettingsPageBase, and desktop components still provide Avalonia controls through the existing registration APIs.

Minimal Package Update

<ItemGroup>
  <PackageReference Include="LanMountainDesktop.PluginSdk" Version="5.0.0" />
</ItemGroup>
{
  "apiVersion": "5.0.0"
}

Validation

After updating package versions and rebuilding the plugin, verify that the generated .laapp contains the rebuilt assembly, plugin.json, and .deps.json next to the plugin entry assembly.