Application Management Overview

Straipsnis
03/13/2024

All applications tend to share a common set of functionality that applies to application implementation and management. This topic provides an overview of the functionality in the Application class for creating and managing applications.

The Application Class

In WPF, common application-scoped functionality is encapsulated in the Application class. The Application class includes the following functionality:

Tracking and interacting with application lifetime.
Retrieving and processing command-line parameters.
Detecting and responding to unhandled exceptions.
Sharing application-scope properties and resources.
Managing windows in standalone applications.
Tracking and managing navigation.

How to Perform Common Tasks Using the Application Class

If you are not interested in all of the details of the Application class, the following table lists some of the common tasks for Application and how to accomplish them. By viewing the related API and topics, you can find more information and sample code.

Task	Approach
Get an object that represents the current application	Use the Application.Current property.
Add a startup screen to an application	See Add a Splash Screen to a WPF Application.
Start an application	Use the Application.Run method.
Stop an application	Use the Shutdown method of the Application.Current object.
Get arguments from the command line	Handle the Application.Startup event and use the StartupEventArgs.Args property. For an example, see the Application.Startup event.
Get and set the application exit code	Set the ExitEventArgs.ApplicationExitCode property in the Application.Exit event handler or call the Shutdown method and pass in an integer.
Detect and respond to unhandled exceptions	Handle the DispatcherUnhandledException event.
Get and set application-scoped resources	Use the Application.Resources property.
Use an application-scope resource dictionary	See Use an Application-Scope Resource Dictionary.
Get and set application-scoped properties	Use the Application.Properties property.
Get and save an application's state	See Persist and Restore Application-Scope Properties Across Application Sessions.
Manage non-code data files, including resource files, content files, and site-of-origin files.	See WPF Application Resource, Content, and Data Files.
Manage windows in standalone applications	See WPF Windows Overview.
Track and manage navigation	See Navigation Overview.

The Application Definition

To utilize the functionality of the Application class, you must implement an application definition. A WPF application definition is a class that derives from Application and is configured with a special MSBuild setting.

Implementing an Application Definition

A typical WPF application definition is implemented using both markup and code-behind. This allows you to use markup to declaratively set application properties, resources, and register events, while handling events and implementing application-specific behavior in code-behind.

The following example shows how to implement an application definition using both markup and code-behind:

<Application 
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
  x:Class="SDKSample.App" />

using System.Windows;

namespace SDKSample
{
    public partial class App : Application { }
}


Imports System.Windows

Namespace SDKSample
    Partial Public Class App
        Inherits Application
    End Class
End Namespace

To allow a markup file and code-behind file to work together, the following needs to happen:

In markup, the Application element must include the x:Class attribute. When the application is built, the existence of x:Class in the markup file causes MSBuild to create a partial class that derives from Application and has the name that is specified by the x:Class attribute. This requires the addition of an XML namespace declaration for the XAML schema (xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml").
In code-behind, the class must be a partial class with the same name that is specified by the x:Class attribute in markup and must derive from Application. This allows the code-behind file to be associated with the partial class that is generated for the markup file when the application is built (see Building a WPF Application).

Note

When you create a new WPF Application project or WPF Browser Application project using Visual Studio, an application definition is included by default and is defined using both markup and code-behind.

This code is the minimum that is required to implement an application definition. However, an additional MSBuild configuration needs to be made to the application definition before building and running the application.

Configuring the Application Definition for MSBuild

Standalone applications and XAML browser applications (XBAPs) require the implementation of a certain level of infrastructure before they can run. The most important part of this infrastructure is the entry point. When an application is launched by a user, the operating system calls the entry point, which is a well-known function for starting applications.

Warning

XBAPs require legacy browsers to operate, such as Internet Explorer and old versions of Firefox. These older browsers are usually unsupported on Windows 10 and Windows 11. Modern browsers no longer support the technology required for XBAP apps due to security risks. Plugins that enable XBAPs are no longer supported. For more information, see Frequently asked questions about WPF browser-hosted applications (XBAP).

Traditionally, developers have needed to write some or all of this code for themselves, depending on the technology. However, WPF generates this code for you when the markup file of your application definition is configured as an MSBuild ApplicationDefinition item, as shown in the following MSBuild project file:

<Project
  DefaultTargets="Build"
                        xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  ...
  <ApplicationDefinition Include="App.xaml" />
  <Compile Include="App.xaml.cs" />
  ...
</Project>

Because the code-behind file contains code, it is marked as an MSBuild Compile item, as is normal.

The application of these MSBuild configurations to the markup and code-behind files of an application definition causes MSBuild to generate code like the following:

using System;
using System.Windows;

namespace SDKSample
{
    public class App : Application
    {
        public App() { }
        [STAThread]
        public static void Main()
        {
            // Create new instance of application subclass
            App app = new App();

            // Code to register events and set properties that were
            // defined in XAML in the application definition
            app.InitializeComponent();

            // Start running the application
            app.Run();
        }

        public void InitializeComponent()
        {
            // Initialization code goes here.
        }
    }
}

Imports System.Windows

Namespace SDKSample
    Public Class App
        Inherits Application
        Public Sub New()
        End Sub
        <STAThread>
        Public Shared Sub Main()
            ' Create new instance of application subclass
            Dim app As New App()

            ' Code to register events and set properties that were
            ' defined in XAML in the application definition
            app.InitializeComponent()

            ' Start running the application
            app.Run()
        End Sub

        Public Sub InitializeComponent()
            ' Initialization code goes here.	
        End Sub
    End Class
End Namespace

The resulting code augments your application definition with additional infrastructure code, which includes the entry-point method Main. The STAThreadAttribute attribute is applied to the Main method to indicate that the main UI thread for the WPF application is an STA thread, which is required for WPF applications. When called, Main creates a new instance of App before calling the InitializeComponent method to register the events and set the properties that are implemented in markup. Because InitializeComponent is generated for you, you don't need to explicitly call InitializeComponent from an application definition like you do for Page and Window implementations. Finally, the Run method is called to start the application.

Getting the Current Application

Because the functionality of the Application class are shared across an application, there can be only one instance of the Application class per AppDomain. To enforce this, the Application class is implemented as a singleton class (see Implementing Singleton in C#), which creates a single instance of itself and provides shared access to it with the staticCurrent property.

The following code shows how to acquire a reference to the Application object for the current AppDomain.

// Get current application
Application current = App.Current;

' Get current application
Dim current As Application = App.Current

Current returns a reference to an instance of the Application class. If you want a reference to your Application derived class you must cast the value of the Current property, as shown in the following example.

// Get strongly-typed current application
App app = (App)App.Current;

' Get strongly-typed current application
Dim appCurrent As App = CType(App.Current, App)

You can inspect the value of Current at any point in the lifetime of an Application object. However, you should be careful. After the Application class is instantiated, there is a period during which the state of the Application object is inconsistent. During this period, Application is performing the various initialization tasks that are required by your code to run, including establishing application infrastructure, setting properties, and registering events. If you try to use the Application object during this period, your code may have unexpected results, particularly if it depends on the various Application properties being set.

When Application completes its initialization work, its lifetime truly begins.

Application Lifetime

The lifetime of a WPF application is marked by several events that are raised by Application to let you know when your application has started, has been activated and deactivated, and has been shut down.

Splash Screen

Starting in the .NET Framework 3.5 SP1, you can specify an image to be used in a startup window, or splash screen. The SplashScreen class makes it easy to display a startup window while your application is loading. The SplashScreen window is created and shown before Run is called. For more information, see Application Startup Time and Add a Splash Screen to a WPF Application.

Starting an Application

After Run is called and the application is initialized, the application is ready to run. This moment is signified when the Startup event is raised:

using System.Windows;

namespace SDKSample
{
    public partial class App : Application
    {
        void App_Startup(object sender, StartupEventArgs e)
        {
            // Application is running
        }
    }
}


Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private Sub App_Startup(ByVal sender As Object, ByVal e As StartupEventArgs)
            ' Application is running
            '</SnippetStartupCODEBEHIND1>
    End Class
End Namespace
'</SnippetStartupCODEBEHIND2>

At this point in an application's lifetime, the most common thing to do is to show a UI.

Showing a User Interface

Most standalone Windows applications open a Window when they begin running. The Startup event handler is one location from which you can do this, as demonstrated by the following code.

<Application
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App" 
  Startup="App_Startup" />

using System.Windows;

namespace SDKSample
{
    public partial class App : Application
    {
        void App_Startup(object sender, StartupEventArgs e)
        {
            // Open a window
            MainWindow window = new MainWindow();
            window.Show();
        }
    }
}


Imports System.Windows

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private Sub App_Startup(ByVal sender As Object, ByVal e As StartupEventArgs)
            ' Open a window
            Dim window As New MainWindow()
            window.Show()
        End Sub
    End Class
End Namespace

Note

The first Window to be instantiated in a standalone application becomes the main application window by default. This Window object is referenced by the Application.MainWindow property. The value of the MainWindow property can be changed programmatically if a different window than the first instantiated Window should be the main window.

When an XBAP first starts, it will most likely navigate to a Page. This is shown in the following code.

<Application 
  x:Class="SDKSample.App"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  Startup="App_Startup" />

using System;
using System.Windows;
using System.Windows.Navigation;

namespace SDKSample
{
    public partial class App : Application
    {
        void App_Startup(object sender, StartupEventArgs e)
        {
            ((NavigationWindow)this.MainWindow).Navigate(new Uri("HomePage.xaml", UriKind.Relative));
        }
    }
}


Imports System.Windows
Imports System.Windows.Navigation

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private Sub App_Startup(ByVal sender As Object, ByVal e As StartupEventArgs)
            CType(Me.MainWindow, NavigationWindow).Navigate(New Uri("HomePage.xaml", UriKind.Relative))
        End Sub
    End Class
End Namespace

If you handle Startup to only open a Window or navigate to a Page, you can set the StartupUri attribute in markup instead.

The following example shows how to use the StartupUri from a standalone application to open a Window.

<Application
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    StartupUri="MainWindow.xaml" />

The following example shows how to use StartupUri from an XBAP to navigate to a Page.

<Application
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    StartupUri="HomePage.xaml" />

This markup has the same effect as the previous code for opening a window.

Note

For more information on navigation, see Navigation Overview.

You need to handle the Startup event to open a Window if you need to instantiate it using a non-parameterless constructor, or you need to set its properties or subscribe to its events before showing it, or you need to process any command-line arguments that were supplied when the application was launched.

Processing Command-Line Arguments

In Windows, standalone applications can be launched from either a command prompt or the desktop. In both cases, command-line arguments can be passed to the application. The following example shows an application that is launched with a single command-line argument, "/StartMinimized":

wpfapplication.exe /StartMinimized

During application initialization, WPF retrieves the command-line arguments from the operating system and passes them to the Startup event handler via the Args property of the StartupEventArgs parameter. You can retrieve and store the command-line arguments using code like the following.

<Application
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App"
  Startup="App_Startup" />

using System.Windows;

namespace SDKSample
{
    public partial class App : Application
    {
        void App_Startup(object sender, StartupEventArgs e)
        {
            // Application is running
            // Process command line args
            bool startMinimized = false;
            for (int i = 0; i != e.Args.Length; ++i)
            {
                if (e.Args[i] == "/StartMinimized")
                {
                    startMinimized = true;
                }
            }

            // Create main application window, starting minimized if specified
            MainWindow mainWindow = new MainWindow();
            if (startMinimized)
            {
                mainWindow.WindowState = WindowState.Minimized;
            }
            mainWindow.Show();
        }
    }
}


Imports System.Windows

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private Sub App_Startup(ByVal sender As Object, ByVal e As StartupEventArgs)
            ' Application is running
            ' Process command line args
            Dim startMinimized As Boolean = False
            Dim i As Integer = 0
            Do While i <> e.Args.Length
                If e.Args(i) = "/StartMinimized" Then
                    startMinimized = True
                End If
                i += 1
            Loop

            ' Create main application window, starting minimized if specified
            Dim mainWindow As New MainWindow()
            If startMinimized Then
                mainWindow.WindowState = WindowState.Minimized
            End If
            mainWindow.Show()
        End Sub
    End Class
End Namespace

The code handles Startup to check whether the /StartMinimized command-line argument was provided; if so, it opens the main window with a WindowState of Minimized. Note that because the WindowState property must be set programmatically, the main Window must be opened explicitly in code.

XBAPs cannot retrieve and process command-line arguments because they are launched using ClickOnce deployment (see Deploying a WPF Application). However, they can retrieve and process query string parameters from the URLs that are used to launch them.

Application Activation and Deactivation

Windows allows users to switch between applications. The most common way is to use the ALT+TAB key combination. An application can only be switched to if it has a visible Window that a user can select. The currently selected Window is the active window (also known as the foreground window) and is the Window that receives user input. The application with the active window is the active application (or foreground application). An application becomes the active application in the following circumstances:

It is launched and shows a Window.
A user switches from another application by selecting a Window in the application.

You can detect when an application becomes active by handling the Application.Activated event.

Likewise, an application can become inactive in the following circumstances:

A user switches to another application from the current one.
When the application shuts down.

You can detect when an application becomes inactive by handling the Application.Deactivated event.

The following code shows how to handle the Activated and Deactivated events to determine whether an application is active.

<Application 
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App"
  StartupUri="MainWindow.xaml"
  Activated="App_Activated" 
  Deactivated="App_Deactivated" />

using System;
using System.Windows;

namespace SDKSample
{
    public partial class App : Application
    {
        bool isApplicationActive;

        void App_Activated(object sender, EventArgs e)
        {
            // Application activated
            this.isApplicationActive = true;
        }

        void App_Deactivated(object sender, EventArgs e)
        {
            // Application deactivated
            this.isApplicationActive = false;
        }
    }
}


Imports System.Windows

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private isApplicationActive As Boolean

        Private Sub App_Activated(ByVal sender As Object, ByVal e As EventArgs)
            ' Application activated
            Me.isApplicationActive = True
        End Sub

        Private Sub App_Deactivated(ByVal sender As Object, ByVal e As EventArgs)
            ' Application deactivated
            Me.isApplicationActive = False
        End Sub
    End Class
End Namespace

A Window can also be activated and deactivated. See Window.Activated and Window.Deactivated for more information.

Note

Neither Application.Activated nor Application.Deactivated is raised for XBAPs.

Application Shutdown

The life of an application ends when it is shut down, which can occur for the following reasons:

A user closes every Window.
A user closes the main Window.
A user ends the Windows session by logging off or shutting down.
An application-specific condition has been met.

To help you manage application shutdown, Application provides the Shutdown method, the ShutdownMode property, and the SessionEnding and Exit events.

Note

Shutdown can only be called from applications that have UIPermission. Standalone WPF applications always have this permission. However, XBAPs running in the Internet zone partial-trust security sandbox do not.

Shutdown Mode

Most applications shut down either when all the windows are closed or when the main window is closed. Sometimes, however, other application-specific conditions may determine when an application shuts down. You can specify the conditions under which your application will shut down by setting ShutdownMode with one of the following ShutdownMode enumeration values:

The default value of ShutdownMode is OnLastWindowClose, which means that an application automatically shuts down when the last window in the application is closed by the user. However, if your application should be shut down when the main window is closed, WPF automatically does that if you set ShutdownMode to OnMainWindowClose. This is shown in the following example.

<Application
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.App"
    ShutdownMode="OnMainWindowClose" />

When you have application-specific shutdown conditions, you set ShutdownMode to OnExplicitShutdown. In this case, it is your responsibility to shut an application down by explicitly calling the Shutdown method; otherwise, your application will continue running even if all the windows are closed. Note that Shutdown is called implicitly when the ShutdownMode is either OnLastWindowClose or OnMainWindowClose.

Note

ShutdownMode can be set from an XBAP, but it is ignored; an XBAP is always shut down when it is navigated away from in a browser or when the browser that hosts the XBAP is closed. For more information, see Navigation Overview.

Session Ending

The shutdown conditions that are described by the ShutdownMode property are specific to an application. In some cases, though, an application may shut down as a result of an external condition. The most common external condition occurs when a user ends the Windows session by the following actions:

Logging off
Shutting down
Restarting
Hibernating

To detect when a Windows session ends, you can handle the SessionEnding event, as illustrated in the following example.

<Application 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.App"
    StartupUri="MainWindow.xaml"
    SessionEnding="App_SessionEnding" />

using System.Windows;

namespace SDKSample
{
    public partial class App : Application
    {
        void App_SessionEnding(object sender, SessionEndingCancelEventArgs e)
        {
            // Ask the user if they want to allow the session to end
            string msg = string.Format("{0}. End session?", e.ReasonSessionEnding);
            MessageBoxResult result = MessageBox.Show(msg, "Session Ending", MessageBoxButton.YesNo);

            // End session, if specified
            if (result == MessageBoxResult.No)
            {
                e.Cancel = true;
            }
        }
    }
}


Imports System.Windows

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private Sub App_SessionEnding(ByVal sender As Object, ByVal e As SessionEndingCancelEventArgs)
            ' Ask the user if they want to allow the session to end
            Dim msg As String = String.Format("{0}. End session?", e.ReasonSessionEnding)
            Dim result As MessageBoxResult = MessageBox.Show(msg, "Session Ending", MessageBoxButton.YesNo)

            ' End session, if specified
            If result = MessageBoxResult.No Then
                e.Cancel = True
            End If
        End Sub
    End Class
End Namespace

In this example, the code inspects the ReasonSessionEnding property to determine how the Windows session is ending. It uses this value to display a confirmation message to the user. If the user does not want the session to end, the code sets Cancel to true to prevent the Windows session from ending.

Note

SessionEnding is not raised for XBAPs.

Exit

When an application shuts down, it may need to perform some final processing, such as persisting application state. For these situations, you can handle the Exit event, as the App_Exit event handler does in the following example. It is defined as an event handler in the App.xaml file. Its implementation is highlighted in the App.xaml.cs and Application.xaml.vb files.

<Application
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="SDKSample.App"
    StartupUri="MainWindow.xaml" 
    Startup="App_Startup" 
    Exit="App_Exit">
    <Application.Resources>
        <SolidColorBrush x:Key="ApplicationScopeResource" Color="White"></SolidColorBrush>
    </Application.Resources>
</Application>

using System.Windows;
using System.IO;
using System.IO.IsolatedStorage;

namespace SDKSample
{
    public partial class App : Application
    {
        string filename = "App.txt";

        public App()
        {
            // Initialize application-scope property
            this.Properties["NumberOfAppSessions"] = 0;
        }

        private void App_Startup(object sender, StartupEventArgs e)
        {
            // Restore application-scope property from isolated storage
            IsolatedStorageFile storage = IsolatedStorageFile.GetUserStoreForDomain();
            try
            {
                using (IsolatedStorageFileStream stream = new IsolatedStorageFileStream(filename, FileMode.Open, storage))
                using (StreamReader reader = new StreamReader(stream))
                {
                    // Restore each application-scope property individually
                    while (!reader.EndOfStream)
                    {
                        string[] keyValue = reader.ReadLine().Split(new char[] {','});
                        this.Properties[keyValue[0]] = keyValue[1];
                    }
                }
            }
            catch (FileNotFoundException ex)
            {
                // Handle when file is not found in isolated storage:
                // * When the first application session
                // * When file has been deleted
            }
        }

        private void App_Exit(object sender, ExitEventArgs e)
        {
            // Persist application-scope property to isolated storage
            IsolatedStorageFile storage = IsolatedStorageFile.GetUserStoreForDomain();
            using (IsolatedStorageFileStream stream = new IsolatedStorageFileStream(filename, FileMode.Create, storage))
            using (StreamWriter writer = new StreamWriter(stream))
            {
                // Persist each application-scope property individually
                foreach (string key in this.Properties.Keys)
                {
                    writer.WriteLine("{0},{1}", key, this.Properties[key]);
                }
            }
        }
    }
}

Imports System.IO
Imports System.IO.IsolatedStorage

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private filename As String = "App.txt"

        Public Sub New()
            ' Initialize application-scope property
            Me.Properties("NumberOfAppSessions") = 0
        End Sub

        Private Sub App_Startup(ByVal sender As Object, ByVal e As StartupEventArgs)
            ' Restore application-scope property from isolated storage
            Dim storage As IsolatedStorageFile = IsolatedStorageFile.GetUserStoreForDomain()
            Try
                Using stream As New IsolatedStorageFileStream(filename, FileMode.Open, storage)
                Using reader As New StreamReader(stream)
                    ' Restore each application-scope property individually
                    Do While Not reader.EndOfStream
                        Dim keyValue() As String = reader.ReadLine().Split(New Char() {","c})
                        Me.Properties(keyValue(0)) = keyValue(1)
                    Loop
                End Using
                End Using
            Catch ex As FileNotFoundException
                ' Handle when file is not found in isolated storage:
                ' * When the first application session
                ' * When file has been deleted
            End Try
        End Sub

        Private Sub App_Exit(ByVal sender As Object, ByVal e As ExitEventArgs)
            ' Persist application-scope property to isolated storage
            Dim storage As IsolatedStorageFile = IsolatedStorageFile.GetUserStoreForDomain()
            Using stream As New IsolatedStorageFileStream(filename, FileMode.Create, storage)
            Using writer As New StreamWriter(stream)
                ' Persist each application-scope property individually
                For Each key As String In Me.Properties.Keys
                    writer.WriteLine("{0},{1}", key, Me.Properties(key))
                Next key
            End Using
            End Using
        End Sub
    End Class
End Namespace

For the complete example, see Persist and Restore Application-Scope Properties Across Application Sessions.

Exit can be handled by both standalone applications and XBAPs. For XBAPs, Exit is raised when in the following circumstances:

An XBAP is navigated away from.
In Internet Explorer, when the tab that is hosting the XBAP is closed.
When the browser is closed.

Exit Code

Applications are mostly launched by the operating system in response to a user request. However, an application can be launched by another application to perform some specific task. When the launched application shuts down, the launching application may want to know the condition under which the launched application shut down. In these situations, Windows allows applications to return an application exit code on shutdown. By default, WPF applications return an exit code value of 0.

Note

When you debug from Visual Studio, the application exit code is displayed in the Output window when the application shuts down, in a message that looks like the following:

The program '[5340] AWPFApp.vshost.exe: Managed' has exited with code 0 (0x0).

You open the Output window by clicking Output on the View menu.

To change the exit code, you can call the Shutdown(Int32) overload, which accepts an integer argument to be the exit code:

// Shutdown and return a non-default exit code
Application.Current.Shutdown(-1);

' Shutdown and return a non-default exit code
Application.Current.Shutdown(-1)

You can detect the value of the exit code, and change it, by handling the Exit event. The Exit event handler is passed an ExitEventArgs which provides access to the exit code with the ApplicationExitCode property. For more information, see Exit.

Note

You can set the exit code in both standalone applications and XBAPs. However, the exit code value is ignored for XBAPs.

Unhandled Exceptions

Sometimes an application may shut down under abnormal conditions, such as when an unanticipated exception is thrown. In this case, the application may not have the code to detect and process the exception. This type of exception is an unhandled exception; a notification similar to that shown in the following figure is displayed before the application is closed.

Screenshot that shows an unhandled exception notification.

From the user experience perspective, it is better for an application to avoid this default behavior by doing some or all of the following:

Displaying user-friendly information.
Attempting to keep an application running.
Recording detailed, developer-friendly exception information in the Windows event log.

Implementing this support depends on being able to detect unhandled exceptions, which is what the DispatcherUnhandledException event is raised for.

<Application
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  x:Class="SDKSample.App"
  StartupUri="MainWindow.xaml"
  DispatcherUnhandledException="App_DispatcherUnhandledException" />

using System.Windows;
using System.Windows.Threading;

namespace SDKSample
{
    public partial class App : Application
    {
        void App_DispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
        {
            // Process unhandled exception

            // Prevent default unhandled exception processing
            e.Handled = true;
        }
    }
}

Imports System.Windows
Imports System.Windows.Threading

Namespace SDKSample
    Partial Public Class App
        Inherits Application
        Private Sub App_DispatcherUnhandledException(ByVal sender As Object, ByVal e As DispatcherUnhandledExceptionEventArgs)
            ' Process unhandled exception

            ' Prevent default unhandled exception processing
            e.Handled = True
        End Sub
    End Class
End Namespace

The DispatcherUnhandledException event handler is passed a DispatcherUnhandledExceptionEventArgs parameter that contains contextual information regarding the unhandled exception, including the exception itself (DispatcherUnhandledExceptionEventArgs.Exception). You can use this information to determine how to handle the exception.

When you handle DispatcherUnhandledException, you should set the DispatcherUnhandledExceptionEventArgs.Handled property to true; otherwise, WPF still considers the exception to be unhandled and reverts to the default behavior described earlier. If an unhandled exception is raised and either the DispatcherUnhandledException event is not handled, or the event is handled and Handled is set to false, the application shuts down immediately. Furthermore, no other Application events are raised. Consequently, you need to handle DispatcherUnhandledException if your application has code that must run before the application shuts down.

Although an application may shut down as a result of an unhandled exception, an application usually shuts down in response to a user request, as discussed in the next section.

Application Lifetime Events

Standalone applications and XBAPs don't have exactly the same lifetimes. The following figure illustrates the key events in the lifetime of a standalone application and shows the sequence in which they are raised.

Standalone Application - Application Object Events

Likewise, the following figure illustrates the key events in the lifetime of an XBAP, and shows the sequence in which they are raised.

XBAP - Application Object Events

Bendrinti naudojant

Application Management Overview

The Application Class

How to Perform Common Tasks Using the Application Class

The Application Definition

Implementing an Application Definition

Configuring the Application Definition for MSBuild

Getting the Current Application

Application Lifetime

Splash Screen

Starting an Application

Showing a User Interface

Processing Command-Line Arguments

Application Activation and Deactivation

Application Shutdown

Shutdown Mode

Session Ending

Exit

Exit Code

Unhandled Exceptions

Application Lifetime Events

See also

Papildomi ištekliai