Description
When using the Rustino native notifications API on Windows, toast notifications are silently swallowed by the operating system if the provided app_id is not tied to a registered AppUserModelID (AUMID) via a Start Menu .lnk shortcut.
The library executes without throwing any errors, giving the false impression that the notification was successfully displayed, but nothing appears in the Windows Action Center. This makes it impossible to use native notifications for standard, unpackaged executable applications (.exe builds) out of the box.
Steps to Reproduce
- Build an application that consumes the Rustino notification API as a standalone
.exe.
- Trigger a notification using a custom
app_id (e.g., "Ivy Tendril").
- Observe that no errors are thrown, but the notification never appears on the screen.
Validation & The PowerShell Hack
To isolate the issue and prove it's entirely tied to AUMID registration, we tested a workaround. We replaced our custom app_id with the built-in Windows PowerShell AUMID:
{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WindowsPowerShell\v1.0\powershell.exe
As soon as we injected this known, pre-registered AUMID, the Rustino notifications rendered perfectly on the desktop (though naturally displaying the PowerShell name and icon). This confirms that the lack of a registered Start Menu shortcut is the sole blocker.
Expected Behavior
Native notifications should either:
- Work out of the box for unpackaged Win32 applications, OR
- Provide a clear error/warning that the
app_id is unregistered.
Proposed Solution
We suggest one of the following approaches:
- Feature: Add a helper method in
Rustino.Native (perhaps Rustino::register_aumid(app_id)) that uses the COM IShellLink and IPropertyStore interfaces to automatically create the required Start Menu shortcut upon application startup.
- Documentation: Explicitly document this Windows limitation in the README, warning developers that they must manually create a Start Menu
.lnk via an installer (MSI/InnoSetup) or a C# COM script before the notifications API will function on Windows 10/11.
Description
When using the Rustino native notifications API on Windows, toast notifications are silently swallowed by the operating system if the provided
app_idis not tied to a registeredAppUserModelID(AUMID) via a Start Menu.lnkshortcut.The library executes without throwing any errors, giving the false impression that the notification was successfully displayed, but nothing appears in the Windows Action Center. This makes it impossible to use native notifications for standard, unpackaged executable applications (
.exebuilds) out of the box.Steps to Reproduce
.exe.app_id(e.g.,"Ivy Tendril").Validation & The PowerShell Hack
To isolate the issue and prove it's entirely tied to AUMID registration, we tested a workaround. We replaced our custom
app_idwith the built-in Windows PowerShell AUMID:{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WindowsPowerShell\v1.0\powershell.exeAs soon as we injected this known, pre-registered AUMID, the Rustino notifications rendered perfectly on the desktop (though naturally displaying the PowerShell name and icon). This confirms that the lack of a registered Start Menu shortcut is the sole blocker.
Expected Behavior
Native notifications should either:
app_idis unregistered.Proposed Solution
We suggest one of the following approaches:
Rustino.Native(perhapsRustino::register_aumid(app_id)) that uses the COMIShellLinkandIPropertyStoreinterfaces to automatically create the required Start Menu shortcut upon application startup..lnkvia an installer (MSI/InnoSetup) or a C# COM script before the notifications API will function on Windows 10/11.