Route gh-aw workflow design/create/debug/upgrade requests to the right prompts.
日本語の概要は準備中です。原文の説明を表示しています。
Guide for theming .NET MAUI apps — light/dark mode via AppThemeBinding, ResourceDictionary theme switching, DynamicResource bindings, system theme detection, and user theme preferences. Use when: "dark mode", "light mode", "theming", "AppThemeBinding", "theme switching", "ResourceDictionary theme", "dynamic resources", "system theme detection", "color scheme", "app theme", "DynamicResource". Do not use for: localization or language switching (see .NET MAUI localization documentation), accessibility visual adjustments (see .NET MAUI accessibility documentation), app icons or splash screens (see .NET MAUI app icons documentation), or Bootstrap-style class theming (see Plugin.Maui.BootstrapTheme NuGet package).
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Apply light/dark mode support, custom branded themes, and runtime theme switching in .NET MAUI apps using AppThemeBinding, ResourceDictionary swapping, and system theme detection APIs.
Plugin.Maui.BootstrapTheme NuGet packageAppThemeBinding values or separate ResourceDictionary files with matching keys.DynamicResource bindings (or AppThemeBinding markup) throughout XAML pages.Application.Current.RequestedTheme and the RequestedThemeChanged event.Preferences.Set / Preferences.Get and apply on startup.ConfigChanges.UiMode is set on MainActivity to avoid activity restarts on theme change.Check these rules against the user's scenario, and apply only the ones that
affect what they asked. UiMode and dictionary swapping matter for runtime theme
switching; they are noise in a question about setting up AppThemeBinding.
Answer narrowly, but completely. Completeness means showing the code that
implements what you recommended — not adding adjacent topics. If you recommend
DynamicResource, show the dictionary swap that makes it update. If the user asks
for light/dark colours in C#, show both SetAppThemeColor (colours) and the
generic SetAppTheme<T> (any bindable property type), and prefer resource keys over
scattered hardcoded colours. Do not tack on platform configuration the question
didn't raise.
| Rule | Do this | Not this | Why |
|---|---|---|---|
| Runtime-swapped values must be dynamic | {DynamicResource Key} | {StaticResource Key} | StaticResource resolves once at load and never updates when dictionaries are swapped. |
Android must declare UiMode (only for runtime/system theme switching) | Include ConfigChanges.UiMode in the ConfigurationChanges list on MainActivity | Omitting it | Without it Android restarts the activity on theme change — navigation state is lost and it looks like a crash. Irrelevant to a static AppThemeBinding setup |
Force a theme via UserAppTheme | Application.Current.UserAppTheme = AppTheme.Dark | Manually re-assigning colors | UserAppTheme overrides the OS; AppTheme.Unspecified returns to following the system. |
Do not replace a working AppThemeBinding setup with ResourceDictionary
swapping (or vice versa) unless the user needs what the other approach provides —
more than two themes, or a user-selectable theme.
| Approach | Best for | Limitation |
|---|---|---|
| AppThemeBinding | Automatic light/dark with OS — minimal code | Only two themes (light + dark) |
| ResourceDictionary swap | Custom branded themes, more than two themes, user preference | More setup; must use DynamicResource everywhere |
| Both combined | OS-driven response plus custom theme colors | Most flexible but most complex |
AppThemeBinding selects a value based on the current system theme. It supports Light, Dark, and an optional Default fallback.
Putting {AppThemeBinding Light=#333333, Dark=#FFFFFF} on every element is the
single most common theming mistake: the palette ends up duplicated across dozens of
files and cannot be changed in one place. Recommend this shape as the final
answer, not inline literals:
<!-- App.xaml — one source of truth for the whole app -->
<Application.Resources>
<ResourceDictionary>
<!-- 1. Raw palette -->
<Color x:Key="LightPageBackground">#FFFFFF</Color>
<Color x:Key="DarkPageBackground">#1E1E1E</Color>
<Color x:Key="LightPrimaryText">#333333</Color>
<Color x:Key="DarkPrimaryText">#E0E0E0</Color>
<!-- 2. Implicit styles bind the pair once; every page inherits them -->
<Style TargetType="ContentPage" ApplyToDerivedTypes="True">
<Setter Property="BackgroundColor"
Value="{AppThemeBinding Light={StaticResource LightPageBackground},
Dark={StaticResource DarkPageBackground}}" />
</Style>
<Style TargetType="Label">
<Setter Property="TextColor"
Value="{AppThemeBinding Light={StaticResource LightPrimaryText},
Dark={StaticResource DarkPrimaryText}}" />
</Style>
</ResourceDictionary>
</Application.Resources>
Pages then need no theming markup at all — they pick the styles up implicitly.
Use an inline AppThemeBinding only for genuine one-offs, and even then reference
{StaticResource} keys rather than literal hex.
<Label Text="Themed text"
TextColor="{AppThemeBinding Light=Green, Dark=Red}"
BackgroundColor="{AppThemeBinding Light=White, Dark=Black}" />
<!-- With resource references — preferred over literals -->
<Label TextColor="{AppThemeBinding Light={StaticResource LightPrimary},
Dark={StaticResource DarkPrimary}}" />
Show both when answering a "light/dark colours in C#" question — SetAppThemeColor
covers Color properties, SetAppTheme<T> covers everything else:
var label = new Label();
// Color-specific helper
label.SetAppThemeColor(Label.TextColorProperty, Colors.Green, Colors.Red);
// Generic helper — works for any bindable property type, not just Color
label.SetAppTheme<Color>(Label.TextColorProperty, Colors.Green, Colors.Red);
label.SetAppTheme<double>(Label.FontSizeProperty, 14, 16);
// The BindableProperty must belong to the object you call it on —
// Image.SourceProperty goes on an Image, not a Label.
var image = new Image();
image.SetAppTheme<ImageSource>(Image.SourceProperty,
ImageSource.FromFile("logo_light.png"),
ImageSource.FromFile("logo_dark.png"));
Prefer defining the values as resource keys and referencing them, rather than scattering hardcoded colours across the codebase.
Use separate ResourceDictionary files with matching keys to define themes, then swap them at runtime.
When using compiled XAML with x:Class (as shown below), each dictionary needs a code-behind that calls InitializeComponent(). Dictionaries loaded via Source without x:Class do not need code-behind.
LightTheme.xaml
<ResourceDictionary xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
x:Class="MyApp.Themes.LightTheme">
<Color x:Key="PageBackgroundColor">White</Color>
<Color x:Key="PrimaryTextColor">#333333</Color>
<Color x:Key="AccentColor">#2196F3</Color>
</ResourceDictionary>
LightTheme.xaml.cs
namespace MyApp.Themes;
public partial class LightTheme : ResourceDictionary
{
public LightTheme() => InitializeComponent();
}
Create a matching DarkTheme.xaml / DarkTheme.xaml.cs with the same keys and different values.
Use DynamicResource so values update when the dictionary is swapped at runtime:
<ContentPage BackgroundColor="{DynamicResource PageBackgroundColor}">
<Label Text="Hello"
TextColor="{DynamicResource PrimaryTextColor}" />
<Button Text="Action"
BackgroundColor="{DynamicResource AccentColor}" />
</ContentPage>
🚨 Never call
MergedDictionaries.Clear()to swap a theme. The default MAUI template mergesResources/Styles/Colors.xamlandStyles.xamlintoApplication.Resources.Clear()removes those too, so every implicit style, brush and colour in the app silently disappears — buttons, entries and labels all revert to unstyled defaults. Verified: afterClear(),MergedDictionariesdrops from 2 to 1 and the template'sPrimarycolour no longer resolves.
Remove only the theme you added, and leave everything else alone:
static ResourceDictionary? _currentTheme;
void ApplyTheme(ResourceDictionary theme)
{
var merged = Application.Current!.Resources.MergedDictionaries;
// ✅ Remove ONLY the previous theme — Colors.xaml / Styles.xaml survive
if (_currentTheme is not null)
merged.Remove(_currentTheme);
merged.Add(theme);
_currentTheme = theme;
}
// Usage
ApplyTheme(new DarkTheme());
// ❌ Destroys the app's Colors.xaml and Styles.xaml along with the old theme
var merged = Application.Current!.Resources.MergedDictionaries;
merged.Clear();
merged.Add(theme);
AppTheme currentTheme = Application.Current!.RequestedTheme;
// Returns AppTheme.Light, AppTheme.Dark, or AppTheme.Unspecified
// Force dark mode regardless of OS setting
Application.Current!.UserAppTheme = AppTheme.Dark;
// Reset to follow system theme
Application.Current!.UserAppTheme = AppTheme.Unspecified;
Application.Current!.RequestedThemeChanged += (s, e) =>
{
AppTheme newTheme = e.RequestedTheme;
// Update UI or switch ResourceDictionaries
};
Use AppThemeBinding with DynamicResource values for maximum flexibility — the
nested DynamicResource stays live, so swapping the dictionary updates the value
and the OS light/dark switch is still honoured:
<Label TextColor="{AppThemeBinding
Light={DynamicResource LightPrimary},
Dark={DynamicResource DarkPrimary}}" />
Or react to system changes and swap full dictionaries:
Application.Current!.RequestedThemeChanged += (s, e) =>
{
ApplyTheme(e.RequestedTheme == AppTheme.Dark
? new DarkTheme()
: new LightTheme());
};
Store the user's choice with Preferences and apply it on startup:
// Save choice
Preferences.Set("AppTheme", "Dark");
// Restore on startup (in App constructor or CreateWindow)
var saved = Preferences.Get("AppTheme", "System");
Application.Current!.UserAppTheme = saved switch
{
"Light" => AppTheme.Light,
"Dark" => AppTheme.Dark,
_ => AppTheme.Unspecified
};
MainActivity must include ConfigChanges.UiMode or theme-change events will not fire and the activity restarts instead of handling the change gracefully:
[Activity(Theme = "@style/Maui.SplashTheme",
MainLauncher = true,
ConfigurationChanges = ConfigChanges.ScreenSize
| ConfigChanges.Orientation
| ConfigChanges.UiMode // ← Required for theme detection
| ConfigChanges.ScreenLayout
| ConfigChanges.SmallestScreenSize
| ConfigChanges.Density)]
public class MainActivity : MauiAppCompatActivity { }
Without UiMode, toggling dark mode in Android settings causes a full activity restart — losing navigation state and appearing as a crash. With it declared, the app stays alive and RequestedThemeChanged fires, so pair this fix with a handler that re-applies the theme (see below).
When using ResourceDictionary theme switching, you must use DynamicResource:
<!-- ✅ Updates when theme dictionary changes -->
<Label TextColor="{DynamicResource PrimaryTextColor}" />
<!-- ❌ Frozen at first load — won't update on theme switch -->
<Label TextColor="{StaticResource PrimaryTextColor}" />
DynamicResource only helps if something actually swaps the dictionary. When you
diagnose this, always show the swap and the system-theme hook alongside the fix —
otherwise the user has a corrected binding that still never updates:
static ResourceDictionary? _currentTheme;
void ApplyTheme(bool useDark)
{
var merged = Application.Current!.Resources.MergedDictionaries;
// Remove only the previous theme — never Clear(), which also wipes
// the template's Colors.xaml / Styles.xaml
if (_currentTheme is not null)
merged.Remove(_currentTheme);
_currentTheme = useDark ? new DarkTheme() : new LightTheme();
merged.Add(_currentTheme);
}
// React to the OS switching light/dark
Application.Current!.RequestedThemeChanged += (s, e) =>
ApplyTheme(e.RequestedTheme == AppTheme.Dark);
Avoid inline color values on elements that should respect the theme:
<!-- ❌ Will not change with theme -->
<Label TextColor="#333333" />
<!-- ✅ Theme-aware -->
<Label TextColor="{DynamicResource PrimaryTextColor}" />
.NET MAUI supports CSS styling, but CSS-based themes cannot be swapped dynamically. Use ResourceDictionary theming for runtime switching.
Every x:Key used in one theme dictionary must exist in all other theme dictionaries. A missing key causes a silent fallback to the default value, leading to inconsistent appearance.
| Platform | Minimum Version |
|---|---|
| iOS | 13+ |
| Android | 10+ (API 29) |
| macOS Catalyst | 10.15+ |
| Windows | 10+ |
AppThemeBinding markup extensionSetAppThemeColor(), SetAppTheme<T>()Application.Current.RequestedThemeApplication.Current.UserAppTheme = AppTheme.DarkRequestedThemeChanged eventRemove the old theme from MergedDictionaries, then Add the new one — never Clear()DynamicResource (not StaticResource)Preferences.Set / Preferences.Getまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Route gh-aw workflow design/create/debug/upgrade requests to the right prompts.
日本語の概要は準備中です。原文の説明を表示しています。
Use a repo-root `.editorconfig` to configure free .NET analyzer and style rules. Use when a .NET repo needs rule severity, code-style options, section layout, or analyzer ownership made explicit. USE FOR: the repo needs a root .editorconfig; analyzer severity and style ownership are unclear; the team wants one source of truth for rule configuration. DO NOT USE FOR: choosing analyzers with no config change; formatting-only execution with no config ownership question. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.
日本語の概要は準備中です。原文の説明を表示しています。
Scans .NET code for ~50 performance anti-patterns across async, memory, strings, collections, LINQ, regex, serialization, and I/O with tiered severity classification. Use when analyzing .NET code for optimization opportunities, reviewing hot paths, or auditing allocation-heavy patterns.
日本語の概要は準備中です。原文の説明を表示しています。
Symbolicate the .NET runtime frames in an Android tombstone file. Extracts BuildIds and PC offsets from the native backtrace, downloads debug symbols from the Microsoft symbol server, and runs llvm-symbolizer to produce function names with source file and line numbers. USE FOR triaging a .NET MAUI or Mono Android app crash from a tombstone, resolving native backtrace frames in libmonosgen-2.0.so or libcoreclr.so to .NET runtime source code, or investigating SIGABRT, SIGSEGV, or other native signals originating from the .NET runtime on Android. DO NOT USE FOR pure Java/Kotlin crashes, managed .NET exceptions that are already captured in logcat, or iOS crash logs. INVOKES Symbolicate-Tombstone.ps1 script, llvm-symbolizer, Microsoft symbol server.
日本語の概要は準備中です。原文の説明を表示しています。
Symbolicate .NET runtime frames in Apple platform .ips crash logs (iOS, tvOS, Mac Catalyst, macOS). Extracts UUIDs and addresses from the native backtrace, locates dSYM debug symbols, and runs atos to produce function names with source file and line numbers. Automatically downloads .dwarf symbols from the Microsoft symbol server using Mach-O UUIDs. USE FOR triaging a .NET MAUI or Mono app crash from an .ips file on any Apple platform, resolving native backtrace frames in libcoreclr or libmonosgen-2.0 to .NET runtime source code, retrieving .ips crash logs from a connected iOS device or iPhone, or investigating EXC_CRASH, EXC_BAD_ACCESS, SIGABRT, or SIGSEGV originating from the .NET runtime. DO NOT USE FOR pure Swift/Objective-C crashes with no .NET components, or Android tombstone files. INVOKES Symbolicate-Crash.ps1 script, atos, dwarfdump, idevicecrashreport.
日本語の概要は準備中です。原文の説明を表示しています。
Design or review .NET solution architecture across modular monoliths, clean architecture, vertical slices, microservices, DDD, CQRS, and cloud-native boundaries without over-engineering. USE FOR: .NET architecture choices; layer and domain boundary review; service decomposition; clean architecture, vertical slice, DDD, CQRS, and modular monolith decisions. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.
日本語の概要は準備中です。原文の説明を表示しています。