Enforce Snackbar usage only in packaged Windows apps by ne0rrmatrix · Pull Request #3276 · CommunityToolkit/Maui

ne0rrmatrix · 2026-08-02T04:31:19Z

Description of Change

Fixes a regression introduced in CommunityToolkit.Maui v15.0.0 where calling SetShouldEnableSnackbarOnWindows(true) (or otherwise initializing the toolkit's Windows Snackbar/Toast support) in an unpackaged Windows app throws a System.Runtime.InteropServices.COMException (0x80670016):

Package dependency criteria could not be resolved.

or

Unable to load resource dll. Microsoft.WindowsAppRuntime.Insights.Resource.dll

Root Cause

Options.SetShouldEnableSnackbarOnWindows(true) unconditionally registered the app with the Windows App SDK's Microsoft.Windows.AppNotifications.AppNotificationManager, which internally resolves a Windows App Runtime package dependency via the dynamic dependency (Bootstrap) APIs. This registration/resolution only succeeds for packaged (MSIX) applications. When called from an unpackaged app, the underlying WinRT call (IAppNotificationManagerMethods.Register) fails with a COMException, since the required package dependency and its resource DLL (Microsoft.WindowsAppRuntime.Insights.Resource.dll) cannot be resolved outside of a packaged identity context.

Previously (v14.0.1) this registration path was not exercised for unpackaged apps, so the issue was not present until v15.0.0.

Fix

Options.SetShouldEnableSnackbarOnWindows now detects whether the app is running as a packaged app (IsPackagedApp(), via reflection over Windows.ApplicationModel.Package.Current) before calling AppNotificationManager.Default.Register()/Unregister(). For unpackaged apps, registration is skipped entirely and a Trace.WriteLine diagnostic message is emitted instead of allowing the unmanaged COMException to propagate.
Snackbar's constructor now throws a clear, actionable InvalidOperationException (instead of letting the unmanaged/WinRT COMException surface) when:
- SetShouldEnableSnackbarOnWindows(true) was not called, or
- the app is not packaged (MSIX) — since Snackbar on Windows depends on the Windows App SDK AppNotificationManager API, which requires a packaged app identity.
Both exceptions include a HelpLink pointing to the Snackbar documentation describing platform-specific initialization requirements.

Impact

Unpackaged Windows MAUI apps no longer crash with an opaque COMException/missing resource DLL error during startup or when calling SetShouldEnableSnackbarOnWindows(true).
Developers now get a clear, descriptive InvalidOperationException explaining that Snackbar requires a packaged (MSIX) Windows app, with a link to documentation.
Packaged Windows apps are unaffected; AppNotificationManager registration continues to work as before.

Additional Fix: Windows PRI Build Error (`PRI175`/`PRI277`)

While validating the above change, the Windows build of CommunityToolkit.Maui.Sample failed with:

WINAPPSDKGENERATEPROJECTPRIFILE : error PRI175: 0x80073b0f - Processing Resources failed with error: Duplicate Entry.
WINAPPSDKGENERATEPROJECTPRIFILE : error PRI277: 0x80073b0f - Conflicting values for resource 'Files/Microsoft.Maui/Platform/Windows/Styles/Resources.xbf'

Root Cause

CommunityToolkit.Maui.Sample.csproj referenced Microsoft.Maui.Controls with a wildcard version:

<PackageReference Include="Microsoft.Maui.Controls" Version="*" />

The wildcard resolved to 10.0.90, while every other MAUI package in the repo is pinned to 10.0.60 via $(MauiPackageVersion) in Directory.Build.props (including Microsoft.Maui.Controls.Maps and the MAUI assemblies pulled in transitively by the CommunityToolkit.Maui.* project references). The build output confirmed the conflict:

microsoft.maui.controls.core\10.0.90\...\Microsoft.Maui.Controls.dll
microsoft.maui.controls.maps\10.0.60\...\Microsoft.Maui.Controls.Maps.dll

Two different MAUI versions each ship the framework resource Files/Microsoft.Maui/Platform/Windows/Styles/Resources.xbf with different content. When the Windows App SDK PRI generator merges them, it finds the same resource path with conflicting values, producing PRI175/PRI277.

Fix

Pinned Microsoft.Maui.Controls to the repo-wide version so all MAUI packages align on 10.0.60:

<PackageReference Include="Microsoft.Maui.Controls" Version="$(MauiPackageVersion)" />

Note: The <WindowsSdkPackageVersion>10.0.19041.56</WindowsSdkPackageVersion> override in the sample project was initially suspected, but removing it surfaced a different error (MVVMTKCFG0003) — CommunityToolkit.Mvvm 8.4.2 requires that SDK version. That line is correct and was left in place; the actual culprit was the wildcard MAUI version.

Linked Issues

Fixes:

PR Checklist

Has a linked Issue, and the Issue has been approved(bug) or Championed (feature/proposal)
Has tests (if omitted, state reason in description)
Has samples (if omitted, state reason in description)
Rebased on top of main at time of PR
Changes adhere to coding standard
Documentation created or updated: Update Snackbar and Toast documentation to clarify Windows packaging … MicrosoftDocs/CommunityToolkit#655

Additional information

Unpackaged Sample app in Windows now builds and runs in Release mode.

Added runtime checks to ensure Snackbar is enabled and used only in packaged (MSIX) Windows apps, throwing clear exceptions and logging debug messages for unsupported scenarios. Introduced IsPackagedApp() helper method for packaging detection. Updated project file to use $(MauiPackageVersion) for Microsoft.Maui.Controls reference. Improved error handling and developer guidance.

Copilot

Pull request overview

This PR fixes a Windows regression where enabling/initializing Snackbar in unpackaged Windows apps can throw WinRT COMExceptions by gating Windows App SDK AppNotificationManager registration behind a “packaged app” check and by providing clearer, actionable exceptions when Snackbar is used without the required Windows setup. It also resolves a Windows PRI resource conflict in the sample by aligning the Microsoft.Maui.Controls package version with the repo-wide MAUI version.

Changes:

Guard Windows AppNotificationManager.Register/Unregister calls so they only run in packaged (MSIX) apps; emit a Trace.WriteLine diagnostic otherwise.
Add a Windows-only Snackbar constructor check that throws a clear InvalidOperationException for unpackaged apps (with HelpLink).
Pin Microsoft.Maui.Controls in the sample project to $(MauiPackageVersion) to avoid mixed-MAUI resource conflicts.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/CommunityToolkit.Maui/Options.shared.cs	Gates Windows App SDK notification registration/unregistration behind packaged-app detection and logs diagnostics when unsupported.
src/CommunityToolkit.Maui/Alerts/Snackbar/Snackbar.shared.cs	Adds a Windows-only guard to throw a clearer exception when `Snackbar` is used in an unpackaged app.
samples/CommunityToolkit.Maui.Sample/CommunityToolkit.Maui.Sample.csproj	Aligns `Microsoft.Maui.Controls` package version with the repo-wide MAUI version to prevent PRI build conflicts.

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

TheCodeTraveler · 2026-08-02T05:50:31Z

 				Alerts.Snackbar.HandleSnackbarAction(args);
 			}
+
+			static bool IsPackagedApp()


Is it possible to refactor this so that it doesn't require a try/catch block? Using a try/catch block is an expensive operation and if we can avoid it, we should. But if we can't, that's ok too.

I removed try/catch and replaced it with a reflection call

I changed it to not use reflection now and it returns true for non null

TheCodeTraveler · 2026-08-02T05:51:06Z

 	internal static TimeSpan GetDefaultTimeSpan() => TimeSpan.FromSeconds(3);

+#if WINDOWS
+	static bool IsPackagedApp()


Is it possible to refactor this method so that it doesn't require a try/catch block? Using a try/catch block is an expensive operation and if we can avoid it, we should. But if we can't, that's ok too.

I removed try/catch and replaced it with a reflection call

I changed it to not use reflection now and it returns true for non null

TheCodeTraveler · 2026-08-02T05:54:23Z

    <MauiFont Include="Resources\Fonts\*" />

-    <PackageReference Include="Microsoft.Maui.Controls" Version="*" />
+    <PackageReference Include="Microsoft.Maui.Controls" Version="$(MauiPackageVersion)" />


Is this necessary?

We keep Microsoft.Maui.Controls version as * to ensure the sample app always uses the most recent MuGet release. This allows us to run + test the sample app on the latest version to avoid breaking changes in our library which runs on an older version of Microsoft.Maui.Controls.

The wildcard * caused the sample app to resolve Microsoft.Maui.Controls to the latest NuGet version (10.0.90), while every other MAUI package in the repo — including Microsoft.Maui.Controls.Maps, Microsoft.Maui.Core, and the MAUI assemblies pulled in transitively by the CommunityToolkit.Maui.* project references — was pinned to 10.0.60 via $(MauiPackageVersion).

This version mismatch broke the Windows build because both MAUI 10.0.60 and 10.0.90 ship the same framework resource file (Files/Microsoft.Maui/Platform/Windows/Styles/Resources.xbf) but with different content. When the Windows App SDK PRI generator merged resources from both versions, it found the same path with conflicting values, producing:

By pinning the sample to $(MauiPackageVersion) (10.0.60), all MAUI packages resolve to the same version, eliminating the duplicate resource conflict.

Replaced try-catch with reflection in IsPackagedApp() for Windows in Snackbar.shared.cs and Options.shared.cs. The method now checks for Windows.ApplicationModel.Package via reflection and inspects the static Current property, improving robustness and avoiding direct API calls.

TheCodeTraveler · 2026-08-02T18:36:57Z

Thanks James! Could you open up a Docs PR to note this new Snackbar/Toast behavior for unpackaged apps?

ne0rrmatrix · 2026-08-02T18:49:42Z

Thanks James! Could you open up a Docs PR to note this new Snackbar/Toast behavior for unpackaged apps?

Documentation created! MicrosoftDocs/CommunityToolkit#655

VladislavAntonyuk · 2026-08-04T18:44:22Z

 			};
 		}
+
+		if (!IsPackagedApp())


Probably should be the first check before configurations

Updated as suggested

…w message for use in our toolkit

ne0rmatrix · 2026-08-04T19:54:35Z

I reverted to using try catch again. Otherwise we do not control what the throw message is.

…s apps

Copilot AI review requested due to automatic review settings August 2, 2026 04:31

Copilot started reviewing on behalf of ne0rrmatrix August 2, 2026 04:31 View session

Copilot AI reviewed Aug 2, 2026

View reviewed changes

Comment thread src/CommunityToolkit.Maui/Options.shared.cs

Comment thread src/CommunityToolkit.Maui/Alerts/Snackbar/Snackbar.shared.cs

Comment thread src/CommunityToolkit.Maui/Alerts/Snackbar/Snackbar.shared.cs Outdated

Apply suggestions from code review

e2e7ed2

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

TheCodeTraveler reviewed Aug 2, 2026

View reviewed changes

ne0rrmatrix added 3 commits August 1, 2026 23:12

Simplify IsPackagedApp method implementation

190c0da

Simplify IsPackagedApp method implementation

dd98d3f

TheCodeTraveler added the pending documentation This feature requires documentation label Aug 2, 2026

ne0rrmatrix added 2 commits August 2, 2026 11:49

Merge branch 'main' into FixComException

2332c44

Merge branch 'main' into FixComException

fb57990

VladislavAntonyuk reviewed Aug 4, 2026

View reviewed changes

Add back the try catch. We are doing this so that we control the thro…

007333b

…w message for use in our toolkit

Refactor Snackbar initialization error handling for unpackaged Window…

95c0604

…s apps

Uh oh!

Conversation

ne0rrmatrix commented Aug 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of Change

Root Cause

Fix

Impact

Additional Fix: Windows PRI Build Error (PRI175/PRI277)

Root Cause

Fix

Linked Issues

PR Checklist

Additional information

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheCodeTraveler commented Aug 2, 2026

Uh oh!

ne0rrmatrix commented Aug 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ne0rmatrix commented Aug 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ne0rrmatrix commented Aug 2, 2026 •

edited

Loading

Additional Fix: Windows PRI Build Error (`PRI175`/`PRI277`)