Is it possible to use WNS without the Windows App SDK in a native C++ WinUI 2 XAML-hosted application?

Question

Is it possible to use WNS without the Windows App SDK in a native C++ WinUI 2 XAML-hosted application?

Rohan Pande 515

Hi,

I'm building a native C++ desktop application that hosts XAML content. The application is currently unpackaged, and I'd like to implement Windows Push Notifications.

While researching, I couldn't find any documentation that explicitly states whether Windows Push Notification Services (WNS) require the Windows App SDK, or whether there's a supported native Win32 approach without it.

I was able to implement Windows Push Notifications in a WinUI 3 application (unpackaged) using the Windows App SDK.

However, my another variant application uses WinUI 2 (XAML hosting), and I'm trying to understand whether the Windows App SDK is actually required for WNS or whether there's a supported alternative for this scenario.

Could someone please clarify the following?

Does using WNS require the Windows App SDK, or can it be used directly from a native Win32/C++ application
If WNS can be used without the Windows App SDK, is it supported for unpackaged / packaged with external location desktop applications?
If the Windows App SDK is required, is that because WNS itself depends on it, or because the SDK provides the supported client APIs for desktop applications?
Are there any official Microsoft documents that describe these requirements and supported scenarios?

I wasn't able to find documentation that clearly answers these questions, so any clarification or pointers to the relevant documentation would be greatly appreciated.

Thank you!

Taki Ly (WICLOUD CORPORATION) 5,055 Reputation points Microsoft External Staff Moderator

2026-07-09T10:51:00.6266667+00:00

Hi @Rohan Pande ,

I'm looking into this issue and will get back to you as soon as possible.

Thank you for your patience!

Answer accepted by question author

0 additional answers

Your answer

Taki Ly (WICLOUD CORPORATION) 5,055 Reputation points Microsoft External Staff Moderator

2026-07-09T10:51:00.6266667+00:00

Hi @Rohan Pande ,

I'm looking into this issue and will get back to you as soon as possible.

Thank you for your patience!

Answer 1

Taki Ly (WICLOUD CORPORATION) 5,055 Microsoft External Staff Moderator

Hello @Rohan Pande ,

To double-check this behavior, I built a quick native C++ Win32 repro without the Windows App SDK. While it compiles perfectly using just the Windows SDK, calling PushNotificationChannelManager::CreatePushNotificationChannelForApplicationAsync() in a truly unpackaged process results in an HRESULT 0x80070490 (Element not found) error. However, when I packaged that exact same executable with external location (sparse packaging) and ran it again, the API successfully requested and received a channel URI from WNS. This confirms that if your app is truly unpackaged, invoking this native API directly from C++ will typically fail, but granting it an identity unlocks the native feature.

The reason the Windows App SDK is often mentioned in these scenarios is that it provides an alternative client API (Microsoft.Windows.PushNotifications.PushNotificationManager). This alternative approach leverages Azure Active Directory for identity, essentially bypassing the OS's strict package identity requirement.

Regarding your deployment scenarios, if you prefer to use WNS without the Windows App SDK, your application would need to be either MSIX packaged or "packaged with external location". This approach grants your Win32 application the necessary package identity while allowing you to keep your existing executable and custom installer. Truly unpackaged apps without the SDK would generally not be supported for WNS.

On the other hand, if you choose to use the Windows App SDK to handle notifications, it might be helpful to note that you don't actually need to migrate your UI to WinUI 3. You can simply integrate the SDK into your existing Win32/WinUI 2 project. However, please keep in mind that for a completely unpackaged app, the App SDK's push notifications only support limited functionality, primarily foreground notifications without background COM activation.

For further reading, I'd suggest taking a look at a few specific Microsoft documents that outline these nuances:

The Quickstart for Push notifications in the Windows App SDK contains a "Packaging requirements" table that confirms the limited functionality for truly unpackaged applications.
To explore the native route, the Grant package identity by packaging with external location documentation illustrates how you might unlock push notifications without altering your current deployment model.
Additionally, the WNS overview clarifies that the classic channel request methods are geared towards UWP or applications holding a package identity.

I hope this helps clarify the underlying requirements and provides some guidance on whether to adopt sparse packaging or integrate the App SDK for your current architecture. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Rohan Pande 515 Reputation points

2026-07-10T04:47:25.33+00:00

Hey, thanks for the information I am also at the same point where I get the error (Element not found) need some help what all steps did you do to make your solution to make it as "packaged with external location"

There are certificate related steps which honestly confused me a lot... Could you help me here in how did you converted your app into package with external location?
Taki Ly (WICLOUD CORPORATION) 5,055 Reputation points Microsoft External Staff Moderator

2026-07-10T09:22:34.5166667+00:00

Hi @Rohan Pande ,

Below is a concise sequence you might consider following to set up the external location package:

First, you would link your executable to the package identity by embedding a fusion manifest containing an <msix> element into your .exe using the mt.exe tool.

Next, you can create the identity package directory with an AppxManifest.xml and pack it into an .msix file using the makeappx pack command.

For the certificate, you can generate a self-signed certificate in PowerShell using New-SelfSignedCertificate. It is important that the Subject exactly matches the Publisher name in your manifests.

After exporting this certificate to a .cer file, the crucial step is to open an elevated PowerShell window and import it into the local machine's Trusted People store using the Import-Certificate cmdlet. This establishes the necessary trust for the OS.

Once the system trusts the certificate, you can sign the .msix package using signtool.exe.

Finally, you would register the package using Add-AppxPackage, making sure to pass the -ExternalLocation parameter pointing to the folder containing your executable.

For a comprehensive list of the exact PowerShell commands for each of these steps, I highly recommend referencing the official guide on Granting package identity by packaging with external location manually.

I hope this overview helps clear up the workflow. Please let me know if you run into any further issues along the way.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Taki Ly (WICLOUD CORPORATION) 5,055 Reputation points Microsoft External Staff Moderator

2026-07-14T07:05:55.6866667+00:00
Hi @Rohan Pande ,

To help clarify the signing requirement, it may apply not only to deployment scenarios but also to certain local development and debugging workflows.

When an application depends on a package identity (for example, when testing features that require package identity such as WNS), Windows typically requires the identity package to be registered. In many cases, Windows will not register a package containing an executable unless the package is signed and trusted.

For local development, you may consider using a self-signed certificate and trusting it on your development machine so the package can be registered and tested. For production deployment, a certificate issued by a trusted Certificate Authority is typically used so that end-users do not need to manually trust the package.

You may find the following documentation helpful:

Build and sign the identity package

Create a certificate for package signing

I hope this helps clarify why signing can become part of the development workflow in certain packaged application scenarios.
Taki Ly (WICLOUD CORPORATION) 5,055 Reputation points Microsoft External Staff Moderator

2026-07-15T10:48:15.7766667+00:00

Hi @Rohan Pande ,

Have you seen my answer in this post? If you have any question, feel free to reach out.
Taki Ly (WICLOUD CORPORATION) 5,055 Reputation points Microsoft External Staff Moderator

2026-07-17T02:14:19.0933333+00:00

Hi @Rohan Pande ,

As we haven’t heard back from you for a while, we’ll go ahead and close this thread for now. If you still need assistance later, feel free to reach out.

Thank you for your understanding.
Rohan Pande 515 Reputation points

2026-07-22T05:03:28.7433333+00:00

Hey @Taki Ly (WICLOUD CORPORATION) sorry for responding got some other work on priority due to which this item got paused.

We are working on this -- I found something that if we turn on the Developer Mode it doesn't require signing? Is this true?

I tried running Appx command and the app got registered Is doing this valid? Asking this because this will atleast help not require a developer to do steps of generating certificate even for locally running.
Taki Ly (WICLOUD CORPORATION) 5,055 Reputation points Microsoft External Staff Moderator

2026-07-22T06:56:01.37+00:00

Hi @Rohan Pande ,

Great to hear back from you!

1. Regarding Developer Mode and Loose File Registration:

When you enable Developer Mode, Windows allows "loose file registration." By using the -Register parameter with Add-AppxPackage, you can point Windows directly to your uncompressed AppxManifest.xml file.

This bypasses the strict requirement to build the app into a .msix container and sign it with a trusted certificate. This is highly recommended for the local F5 developer loop because (just as you noted) it saves every developer on your team from having to generate and trust self-signed certificates locally.

Just keep in mind that this is specifically a developer environment feature. For your actual production distribution to end-users (where Developer Mode is expected to be disabled), you will still need to package and sign the application properly.

2. Regarding WinUI 2 / Classic WNS Notification Headers:

Since your app uses WinUI 2 and the standard Package Identity (via the sparse package), you are utilizing the classic Windows Push Notification Services (WNS).

The correct documentation detailing the REST APIs, OAuth authentication, and specific request/response headers for classic WNS (Windows Runtime/UWP apps) is below:

Push notification service request and response headers (Classic WNS)

For a broader architectural look at pushing notifications to a classic WNS client, you can also check out the Windows Push Notification Services (WNS) overview.

If you found the information and solutions provided throughout our discussion helpful, I would greatly appreciate it if you could follow this guide as this helps other developers in the community with similar questions find this thread much more easily!
Rohan Pande 515 Reputation points

2026-07-22T07:12:44.73+00:00

But this page which you shared is for Windows Runtime apps and not for WinUI2 apps right? They explicitly say for Windows runtime apps which requires Windows AppSDK
Taki Ly (WICLOUD CORPORATION) 5,055 Reputation points Microsoft External Staff Moderator

2026-07-22T07:36:50.4866667+00:00
Hi @Rohan Pande ,

WinUI 2 is built on UWP, which means it is a "Windows Runtime app". Since your sparse package uses the built-in OS APIs (Windows.Networking.PushNotifications), the "Windows Runtime apps" documentation I shared is what you need.

Windows App SDK (WinUI 3) is the newer framework. It uses an entirely different, decoupled push notification pipeline (Microsoft.Windows.PushNotifications).

So for your WinUI 2 app, you should stick to the "Windows Runtime apps" guide. Let me know if you need help formatting the payloads!
Rohan Pande 515 Reputation points

2026-07-22T07:48:00.69+00:00

Thanks for clarifying that.

I went to the architecture look https://learn.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications/windows-push-notification-services--wns--overview

It says we need to register for the application in Microsoft Store Dashboard could you help here what all to do first to try it out locally? I was able to bypass the certificate atleast for local development but not sure here what all is required (Don't find a specific section regarding this)
Taki Ly (WICLOUD CORPORATION) 5,055 Reputation points Microsoft External Staff Moderator

2026-07-22T10:17:23.2433333+00:00
Hi @Rohan Pande ,

Great question. Unlike the certificate (which you cleverly bypassed for local dev), you cannot bypass the Microsoft Store Dashboard (Partner Center) registration for WNS.

Because WNS doesn't have a "local emulator," it always relies on Microsoft's live cloud servers (notify.windows.com). According to the official documentation on Authenticating your cloud service:

"To send a notification, the cloud service must be authenticated through WNS. The first step in this process occurs when you register your app with the Microsoft Store Dashboard. During the registration process, your app is given a Package security identifier (SID) and a secret key."

Below are the minimal steps to set this up for local development (you do not need to publish or submit the app to the public store):

Reserve a Name: Log into the Microsoft Partner Center (requires a Windows Developer account) and reserve a new App Name. (It can be a hidden/dummy app just for testing).

Update your Local Manifest: In Partner Center, go to Product Management > Product Identity. Copy the exact Package/Identity/Name and Package/Identity/Publisher strings and paste them into your local AppxManifest.xml file.

Get your WNS Credentials: In Partner Center, go to App Management > WNS/Live Services. Here you will find the Application SID (Client ID) and Client Secret.

Use credentials in your Backend: Your backend (or local testing script) will use this SID and Secret to request the OAuth token from Microsoft, which then gives you permission to send HTTP POST requests to your app's channel URI.

Once your local manifest is updated to match the Store identity and registered using your PowerShell script, your local app and the WNS cloud will be linked.
Rohan Pande 515 Reputation points

2026-07-23T07:20:06.3766667+00:00

@Taki Ly (WICLOUD CORPORATION) , thanks this helped. I tried the minimal steps you shared and was able to send a push notification.

I do need a bit of help with one thing, though: I want to use X-WNS-Type as wns/raw because the payload data should be processed by the app and then the notification displayed accordingly. It worked when the app was running in the foreground / background, but not when my application wasn't running.

Could you help me with this? When I used wns/toast, it was able to send even if the application wasn't running, but that wasn't the case with wns/raw.
Taki Ly (WICLOUD CORPORATION) 5,055 Reputation points Microsoft External Staff Moderator

2026-07-23T08:05:45.7+00:00
Hi @Rohan Pande ,

I'm glad to hear that the minimal steps worked and you successfully sent a push notification locally.

Regarding your new observation about wns/raw: What you are experiencing is by design.

wns/toast notifications are handled and rendered directly by the Windows OS (Action Center), so they appear even if your app is completely closed.

wns/raw sends a raw data payload meant strictly for your application's code to process. If your app isn't running, Windows has nowhere to deliver that data, so it is dropped.

To receive wns/raw notifications while the app is closed, you must implement a Background Task (PushNotificationTrigger) with an out-of-process COM server activation to properly wake up your app.

Since the original issue about package identity registration and deployment errors is now resolved, and this Background Task implementation is a completely different architectural topic, could you please open a new thread/question for it? I will be on the lookout and would be more than happy to jump in and help you set it up over there.

Lastly, if the guidance, information, and support provided throughout this discussion have been helpful to you, I would be very happy if you could follow this instruction.

By doing this, you help ensure that other developers in the community facing this exact same issue can find this thread much more easily.

Looking forward to seeing your new thread!
Rohan Pande 515 Reputation points

2026-07-24T05:30:24.9833333+00:00

Yeah sure thanks @Taki Ly (WICLOUD CORPORATION) for the help

Will try out first if I face regarding that will raise issue again in a new post.
Taki Ly (WICLOUD CORPORATION) 5,055 Reputation points Microsoft External Staff Moderator

2026-07-24T07:21:46.0533333+00:00

Hi @Rohan Pande ,

Thank you for the update, and I'm glad the information helped.

If you run into any issues in the future, please feel free to create a new post and I'll be happy to assist.

Thank you and have a great day!