# v2.1.0: Permissions API and Live Notification Availability

v2.1.0: Permissions API and Live Notification Availability

🚀 Two ports from .NET MAUI land in this release: a full Permissions API for checking and
requesting runtime permissions, and live notification-availability detection so apps can tell
when Windows is silently blocking their toasts — plus a scenario fix for Error-severity
notifications.

⚠️ Breaking Changes

• Minimum target Windows version raised. Barbatos.Wpf.Core's TargetFrameworks changed
  from unversioned net10.0-windows;net9.0-windows;net8.0-windows to
  net10.0-windows10.0.17763.0;net9.0-windows10.0.17763.0;net8.0-windows10.0.17763.0 (Windows
  10, version 1809+). This is required to light up the WinRT
  Windows.UI.Notifications.NotificationSetting contract backing the new
  INotificationService.Availability. Consuming projects must target windows10.0.17763.0 or
  higher — most apps already do; if yours targets a bare netX.0-windows TFM, bump it to
  include the Windows version.

✨ What's New

• Permissions — ported MAUI's Permissions API 1:1: the same generic, DI-free static
  surface (Permissions.CheckStatusAsync<T>() / Permissions.RequestAsync<T>(),
  ShouldShowRationale<T>()), no IPermissions interface to register, exactly like MAUI
  itself. Every permission type MAUI ships is present as a nested type — Battery,
  Bluetooth, CalendarRead/CalendarWrite, Camera, ContactsRead/ContactsWrite,
  Flashlight, LaunchApp, LocationWhenInUse/LocationAlways, Maps, Media,
  Microphone, NearbyWifiDevices, NetworkState, Phone, Photos/PhotosAddOnly,
  PostNotifications, Reminders, Sensors, Sms, Speech, StorageRead/StorageWrite,
  Vibrate. On this platform:
  • Most permissions report PermissionStatus.Granted — an unpackaged WPF app has no
    AppxManifest.xml capabilities to check, and .NET MAUI's own Windows implementation
    already just returns Granted for these same permissions.
  • ContactsRead, ContactsWrite, LocationWhenInUse, LocationAlways, Microphone, and
    Sensors throw FeatureNotSupportedException instead of silently reporting Granted —
    MAUI backs these six with real WinRT device-access contracts (ContactManager,
    Geolocator, DeviceAccessInformation, MediaCapture) that need WinRT projections and,
    for some APIs, MSIX packaging, the same machinery Contacts and Geolocation already opt
    out of.
  • Extensible the same way MAUI is: subclass Permissions.BasePlatformPermission to back a
    permission with a real check (e.g. the Windows privacy consent registry).
• INotificationService.Availability (NotificationAvailability) — reads live (never
  cached) whether Windows currently allows the app to display notifications, and why:
  Enabled, DisabledForApplication, DisabledForUser, DisabledByGroupPolicy,
  DisabledByManifest. Needed because Windows silently drops a blocked toast instead of
  raising an error, so Show(...) alone can never tell you it didn't go through.
• INotificationService.OpenSystemSettings() — deep-links to the Windows notifications
  settings page (ms-settings:notifications) so the user can act on what Availability
  reported. The sample's "Notifications" row demonstrates the full pattern: the description
  turns into a warning and an "Open notification settings" button appears whenever
  Availability != Enabled, refreshed on window activation.

🛠️ Fixes

• NotificationContent.Severity = Error now sets the toast's Alarm scenario (stays on
  screen until dismissed, in addition to bypassing Focus Assist) instead of just marking it
  Urgent, so error notifications no longer disappear before they're seen.

📦 Updating via NuGet

```
dotnet add package Barbatos.Wpf.Core --version 2.1.0
```

If your app targets a bare net8.0-windows / net9.0-windows / net10.0-windows TFM, add
the Windows version to keep resolving this package: net8.0-windows10.0.17763.0 (or higher).