Merge pull request #5837 from MicrosoftDocs/main

Auto Publish – main to live - 2025-09-22 23:04 UTC

Author: learn-build-service-prod[bot]

hub/apps/develop/widgets/implement-widget-provider-win32.md

@@ -2,7 +2,7 @@
 title: Implement a widget provider in a win32 app (C++/WinRT)
 description: This article walks you through the process of creating widget provider, implemented in C++/WinRT that provides widget content and responds to widget actions. 
 ms.topic: how-to
-ms.date: 07/06/2022
+ms.date: 09/22/2025
 ms.localizationpriority: medium
 ---
 
@@ -163,7 +163,7 @@ This example will declare some static strings to define the JSON templates for e
 In the latest release, apps that implement Windows widgets can customize the header that is displayed for their widget in the Widgets Board, overriding the default presentation. For more information, see [Customize the widget header area](widget-header-customization.md).
 
 > [!NOTE]
-> Starting with Windows Build [TBD - Build number], apps that implement Windows widgets can choose to populate the widget content with HTML served from a specified URL instead of supplying content in the Adaptive Card schema format in the JSON payload passed from the provider to the Widgets Board. Widget providers must still provide an Adaptive Card JSON payload, so the implementation steps in this walkthrough are applicable to web widgets. For more information, see [Web widget providers](web-widget-providers.md).
+> In the latest release, apps that implement Windows widgets can choose to populate the widget content with HTML served from a specified URL instead of supplying content in the Adaptive Card schema format in the JSON payload passed from the provider to the Widgets Board. Widget providers must still provide an Adaptive Card JSON payload, so the implementation steps in this walkthrough are applicable to web widgets. For more information, see [Web widget providers](web-widget-providers.md).
 
 ```cpp
 // WidgetProvider.h

hub/apps/package-and-deploy/project-properties.md

@@ -2,7 +2,7 @@
 title: Project properties and auto-initializers
 description: Describes the project properties that you can set in your Visual Studio project file to customize how your app is deployed, including configuring auto-initializers.
 ms.topic: article
-ms.date: 08/29/2025
+ms.date: 09/22/2025
 ms.localizationpriority: medium
 ---
 
@@ -24,27 +24,47 @@ All of the auto-initializers are conditionally enabled by default, based on your
   * You can opt out of the bootstrapper/dynamic dependencies auto-initializer in your `.csproj` or `.vcxproj` file via `<WindowsAppSdkBootstrapInitialize>false</WindowsAppSdkBootstrapInitialize>`.
 * Deployment Manager auto-initializer. This is required for framework-dependent packaged apps that make use of main/singleton functionality (for example, push notifications), because the `appxmanifest.xml` file can't express those dependencies.
   * For a self-contained app, you don't need the Deployment Manager auto-initializer because those apps don't support main/singleton functionality.
+  * For more important info, see the section [The Deployment Manager auto-initializer](#the-deployment-manager-auto-initializer) later in this topic.
 * Registration-free activation auto-initializer. This is required for a self-contained app to use manifest-based undocked registration-free Windows Runtime (WinRT) activation (*UndockedRegFreeWinRT*), if the app is running downlevel on an operating system version earlier than Windows 10 May 2019 Update (version 1903; codenamed "19H1").
   * For framework-dependent apps, and for self-contained apps that target Windows 10, version 1903, or later, you don't need the registration-free activation auto-initializer. Those apps can opt out via `<WindowsAppSdkUndockedRegFreeWinRTInitialize>false</WindowsAppSdkUndockedRegFreeWinRTInitialize>`.
 * Compatibility auto-initializer. This is required for an app to use A/B containment facilities to control servicing release behavior. For more info, see [RuntimeCompatibilityOptions](/windows/windows-app-sdk/api/winrt/microsoft.windows.applicationmodel.windowsappruntime.runtimecompatibilityoptions).
   * For apps that don't use A/B containment (which is the default), you don't need the compatibility auto-initializer.
 
-## Project properties
+## The Deployment Manager auto-initializer
+
+When an app that uses the Windows App SDK 1.8 or later starts up, the Deployment Manager auto-initializer runs *by default*. But you can opt out of that happening. This section explains the benefits and caveats of allowing the Deployment Manager auto-initializer to run, and it helps you decide whether or not to opt out.
+
+For your app to make use of functionality in the Main/Singleton packages (for example, push notifications):
+	1. You must use the Deployment API to ensure that those packages are deployed (because the Main/Singleton packages aren't frameworks, but "main" packages, like apps; so they can't be registered as dependencies in your app's appx manifest. Instead, the Deployment API provides the functionality to deploy those packages).
+	2. Because of 1), your app needs to initialize the Deployment Manager by causing [DeploymentManager.Initialize](/windows/windows-app-sdk/api/winrt/microsoft.windows.applicationmodel.windowsappruntime.deploymentmanager.initialize) to be called. Your app can do that either automatically, or explicitly, as we'll see.
+	3. You app needs to be a framework-dependent packaged app so that it takes a dependency on the Main/Singleton packages.
+
+One way of initializing the Deployment Manager is to allow the Deployment Manager auto-initializer to run (see the section [Auto-initializers in the Windows App SDK](#auto-initializers-in-the-windows-app-sdk) earlier in this topic). The Deployment Manager auto-initializer calls [DeploymentManager.Initialize](/windows/windows-app-sdk/api/winrt/microsoft.windows.applicationmodel.windowsappruntime.deploymentmanager.initialize) for you. The other way of initializing the Deployment Manager is to explicitly call **DeploymentManager.Initialize** yourself.
+
+If your app (using the Windows App SDK 1.8 or later) doesn't need the Main/Singleton packages, then you should opt out of the Deployment Manager auto-initializer by setting the **WindowsAppSdkDeploymentManagerInitialize** property to *false* in your app's project file.
 
-These are the properties you can set You can use your app's project file to specify the patch level and disabled changes. Here's an example of how to specify the patch level and disabled changes in your project file :
+If your app (using the Windows App SDK 1.8 or later) *does* need the Main/Singleton packages, then you can either:
+* Allow the Deployment Manager auto-initializer to run (which it does by default),
+* or opt out of the Deployment Manager auto-initializer by setting the **WindowsAppSdkDeploymentManagerInitialize** property to *false* in your app's project file. You should then explicitly call [DeploymentManager.Initialize](/windows/windows-app-sdk/api/winrt/microsoft.windows.applicationmodel.windowsappruntime.deploymentmanager.initialize) yourself.
 
-See the previous section (above) for details about the auto-initializers in the Windows App SDK.
+> [!IMPORTANT]
+> For any process running in the AppContainer, if you cause [DeploymentManager.Initialize](/windows/windows-app-sdk/api/winrt/microsoft.windows.applicationmodel.windowsappruntime.deploymentmanager.initialize) to be called, then your app needs to declare the `packageManagement` [restricted capability](/windows/uwp/packaging/app-capability-declarations#restricted-capabilities) in your [package manifest](/uwp/schemas/appxpackage/appx-package-manifest).
+
+## Project properties
+
+In the table below are the properties that you can set in your app's project file. See the previous section (above) for details about the auto-initializers in the Windows App SDK.
 
 |Property name and description|Values|For more info|
 |-|-|-|
 |**AppxPackage**. Specifies whether or not a WinUI 3 app is packaged.|*false* (for an unpackaged app), or absent (for a packaged app)|[Create a new project for an unpackaged WinUI 3 desktop app](/windows/apps/winui/winui3/create-your-first-winui3-app#unpackaged-create-a-new-project-for-an-unpackaged-c-or-c-winui-3-desktop-app)|
 |**EnableMsixTooling**. Enables the single-project MSIX feature for a project.|*true* (to enable), or absent (to disable)|[Package your app using single-project MSIX](/windows/apps/windows-app-sdk/single-project-msix)|
 |**UseWinUI**. Specifies whether you're using the WinUI 3 user interface framework in your app.|*true*, or absent (for *false*)|[WinUI in the Windows App SDK (WinUI 3)](/windows/apps/winui/winui3/)|
 |**WindowsAppSdkBootstrapInitialize**. Determines whether or not the Windows App SDK leverages the bootstrapper/dynamic dependencies auto-initializer.|*true* (the default for executables), *false* (the default for non-executables)|[Opting out of (or into) auto-initializers](/windows/apps/windows-app-sdk/use-windows-app-sdk-run-time#opting-out-of-or-into-automatic-module-initialization)|
+|**WindowsAppSdkDeploymentManagerInitialize**. Determines whether or not the Windows App SDK leverages the Deployment Manager auto-initializer.|*true* (the default), *false*||
+|**WindowsAppSDKRuntimePatchLevel1**, **WindowsAppSDKRuntimePatchLevel2**, and **WindowsAppSDKDisabledChanges**. Determines whether or not the Windows App SDK leverages the compatibility auto-initializer, and configures any desired compatibility options for Windows App Runtime behavior of changes added in servicing updates.|Various, or absent (to disable the auto-initializer)|[RuntimeCompatibilityOptions](/windows/windows-app-sdk/api/winrt/microsoft.windows.applicationmodel.windowsappruntime.runtimecompatibilityoptions)|
 |**WindowsAppSdkSelfContained**. Determines whether or not an app is deployed *self-contained*.|*true*, or absent (for *false*)|[Windows App SDK deployment guide for self-contained apps](/windows/apps/package-and-deploy/self-contained-deploy/deploy-self-contained-apps)|
 |**WindowsAppSdkUndockedRegFreeWinRTInitialize**. Determines whether or not the Windows App SDK leverages the Registration-free activation auto-initializer.|*true* (the default for executables), *false* (the default for non-executables)|[Opting out of (or into) automatic UndockedRegFreeWinRT support](/windows/apps/package-and-deploy/self-contained-deploy/deploy-self-contained-apps#opting-out-of-or-into-automatic-undockedregfreewinrt-support)|
 |**WindowsPackageType**. Setting `<WindowsPackageType>None</WindowsPackageType>` for an unpackaged app causes the bootstrapper/dynamic dependencies auto-initializer to locate and load a version of the Windows App SDK version that's most appropriate for your app.|*None*, or absent (to disable the auto-initializer)|[Create a new project for an unpackaged WinUI 3 desktop app](/windows/apps/winui/winui3/create-your-first-winui3-app#unpackaged-create-a-new-project-for-an-unpackaged-c-or-c-winui-3-desktop-app)<br/><br/>[Behind the scenes, and opting out of auto-initializers](/windows/apps/windows-app-sdk/use-windows-app-sdk-run-time#behind-the-scenes-and-opting-out-of-automatic-module-initialization)|
-|**WindowsAppSDKRuntimePatchLevel1**, **WindowsAppSDKRuntimePatchLevel2**, and **WindowsAppSDKDisabledChanges**. Determines whether or not the Windows App SDK leverages the compatibility auto-initializer, and configures any desired compatibility options for Windows App Runtime behavior of changes added in servicing updates.|Various, or absent (to disable the auto-initializer)|[RuntimeCompatibilityOptions](/windows/windows-app-sdk/api/winrt/microsoft.windows.applicationmodel.windowsappruntime.runtimecompatibilityoptions)|
 
 ## Example