Application Class

Definition

/// [Windows.Foundation.Metadata.ContractVersion(Windows.Foundation.UniversalApiContract, 65536)]
/// [Windows.Foundation.Metadata.MarshalingBehavior(Windows.Foundation.Metadata.MarshalingType.Agile)]
/// [Windows.Foundation.Metadata.Threading(Windows.Foundation.Metadata.ThreadingModel.Both)]
class Application

[Windows.Foundation.Metadata.ContractVersion(typeof(Windows.Foundation.UniversalApiContract), 65536)]
[Windows.Foundation.Metadata.MarshalingBehavior(Windows.Foundation.Metadata.MarshalingType.Agile)]
[Windows.Foundation.Metadata.Threading(Windows.Foundation.Metadata.ThreadingModel.Both)]
public class Application

Public Class Application

<Application />
 

Inheritance

Object IInspectable Application

Attributes

ContractVersionAttribute MarshalingBehaviorAttribute ThreadingAttribute

Windows requirements

Remarks

The Application class encapsulates an app and provides the following services:

• app entry point, particularly for various activation contracts
• app lifetime management
• app-scoped resources
• unhandled exception detection

The Application object is typically provided in the initial XAML for App.xaml. The default project templates in Visual Studio generate an App class that derives from Application and provides an entry point where you can add initialization code.

The App class associates itself with the corresponding XAML by calling the generated InitializeComponent method in its constructor. You can add additional initialization code to the App constructor, but you will typically only add code to associate handlers to Application events. For other initialization code, you should override one or more initialization methods such as OnLaunched.

The system handles app lifetime by suspending your app whenever the user switches to another app or to the desktop, and resuming your app whenever the user switches back to it. However, the system can also terminate your app while it is suspended in order to free up resources. You should handle the Suspending event to save your app state in case of termination, and override the OnLaunched method to restore your app state. You should handle the Resuming event only if you need to refresh any displayed content that might have changed while the app is suspended. You do not need to restore other app state when the app resumes.

Because of its position in the application model, codegen, and activation sequence, Application has some restrictions on its XAML usage:

• Other than the xmlns declarations and x:Class, no other attribute can appear on the Application root tag.
• Don't attempt to change x:Class values that come from the project template App.xaml pages, there are additional dependencies on using that naming scheme that exist in the build actions.
• Don't wire the Application event handlers in XAML. All event wiring should be done in code (usually in the constructor). Also, you generally use method overrides rather than event syntax for an event (for example, you override OnActivated to respond to that phase of the application life cycle.)
• The only expected properties on an Application instance in XAML is the set of elements to populate the Application.Resources property, using a XAML property element usage. For more info, see Resources. To provide general error handling for any exceptions that your app code doesn't catch, handle the UnhandledException event.

Version history

Constructors

Properties

Methods

Events

Applies to

See also

• Window
• Handle app activation
• Handle app suspend
• Handle app resume