Access to this page requires authorization. You can try signing in or changing directories . Access to this page requires authorization. You can try changing directories . Represents an app that comprises part of or all of the functionality delivered in the package. Element hierarchy <Package> └─ <Applications> └─ <Application> ? optional (zero or one) Parent elements The Application element contains attributes that are common to the extensibility points that pertain to the app. This info is used by other extensibility points to get info about the app. Application attributes are also used as activation info in the startup and management of an instance of the app (in other words, they describe how to start a process, and with what behavior). The StartPage attribute applies only to JavaScript apps. If StartPage isn't specified, then both the Executable and EntryPoint attributes must be specified (and that applies only to C#, C++, or VB apps). uap10 was introduced in Windows 10, version 2004 (10.0; Build 19041) The uap10 namespace (for uap10:RuntimeBehavior and uap10:TrustLevel ) was introduced in Windows 10, version 2004 (10.0; Build 19041). If your package installs on systems older than that, then you need to provide an equivalent combination of attributes (see the following section), otherwise the activation info will be incomplete, and the install will fail. But if your package has <TargetDeviceFamily MinVersion="10.0.19041.0"> , or higher, then it installs only on systems that support the uap10 namespace. In that case, you should use the uap10:RuntimeBehavior and uap10:TrustLevel attributes in preference to the older equivalent combinations (see the following section). Combinations of activation info attributes You can specify activation info attributes on the Application element; and you can optionally specify them on an app-scope Extension element. If they're not specified on Extension , then they're inherited from the parent Application . You specify these attributes in combinations—for example, EntryPoint , RuntimeBehavior , and TrustLevel have overlapping meaning, and they're specified (and/or inherited) in combinations. Here are some valid combinations of activation info attributes. Executable , uap10:RuntimeBehavior ="packagedClassicApp", uap10:TrustLevel =["mediumIL", or "appContainer" (the default if omitted)] Executable , uap10:RuntimeBehavior ="win32App", uap10:TrustLevel ="mediumIL" (for other requirements, see the Description earlier in this topic for uap10:RuntimeBehavior ). Executable , EntryPoint ="windows.fullTrustApplication" (equivalent to uap10:RuntimeBehavior ="packagedClassicApp", uap10:TrustLevel ="mediumIL") Executable , EntryPoint ="windows.partialTrustApplication" (equivalent to uap10:RuntimeBehavior ="packagedClassicApp", uap10:TrustLevel ="appContainer") Executable , EntryPoint ="<anything else>"

As you can see, if your target system doesn't support the uap10 namespace, then you can specify the EntryPoint attribute instead. Similarly, the equivalent of uap10:TrustLevel ="appContainer"` on older systems is EntryPoint ="windows.partialTrustApplication". But it's redundant to specify both uap10:RuntimeBehavior / uap10:TrustLevel and EntryPoint at the same time. But if you do that, then it's an error if they contradict. Universal Windows Platform (UWP) app activations require EntryPoint . So if you specify Executable and uap10:RuntimeBehavior ="windowsApp" (with no EntryPoint ), then that's an error. In this same case, EntryPoint would specify something other than "windows.fullTrustApplication" and "windows.partialTrustApplication"; and values other than those two already say the same thing as uap10:RuntimeBehavior ="windowsApp". So uap10:RuntimeBehavior would be redundant in this case, and you'd specify Executable and EntryPoint . Setting uap10:RuntimeBehavior ="win32App" and uap10:TrustLevel ="appContainer" isn't supported. Setting uap10:TrustLevel="mediumIL" while uap10:RuntimeBehavior="windowsApp" requires the Microsoft.coreAppActivation_8wekyb3d8bbwe Custom Capability. This is also true if uap10:TrustLevel="mediumIL" and EntryPoint is any other value than "windows.fullTrustApplication" or "windows.partialTrustApplication" . You can read more about this custom capability here in Custom Capabilities . Important notes about multi-instancing apps If an app declares SupportsMultipleInstances within the Application element, then all foreground extensions will also be multi-instanced. If the app declares SupportsMultipleInstances within the Application element, then it does not need to be declared at the Extensions level (for example, in a BackgroundTasks or AppService element). The app should only declare SupportsMultipleInstances on background tasks, background audio, or app services. Console apps will always be multi-instanced and must explicitly declare SupportsMultipleInstances . Apps can use the ResourceGroup declaration in the manifest to group multiple background tasks into the same host. This conflicts with multi-instancing, where each activation goes into a separate host. Therefore, an app cannot declare both SupportsMultipleInstances and ResourceGroup in the manifest. For more info about using the SupportsMultipleInstances attribute to support multiple, separate instances of UWP apps, see Create a multi-instance Universal Windows App . Was this page helpful? Need help with this topic? Want to try using Ask Learn to clarify or guide you through this topic? Additional resources Last updated on 2026-06-17