dotnet Exception Handling

.NET Exceptions – System.Deployment.Application.DeploymentException

We finish up the current run of our detailed .NET Exception Handling series with a dive into the System.Deployment.Application.DeploymentException. The DeploymentException is actually a larger parent class to all exceptions that occur during deployment. For example, using the common ClickOnce method of application deployment might run into some issues, and the exception(s) thrown during this process are all derived from DeploymentException.

In today’s article we’ll explore the DeploymentException in more detail by first looking at where it sits in the overall .NET exception hierarchy. We’ll also dig into some fully functional C# code samples that will illustrate how a common ClickOnce application deployment might work, and how attempting to automatically update that application from future releases could result in any number of DeploymentExceptions if you aren’t careful. Let’s get to it!

The Technical Rundown

All .NET exceptions are derived classes of the System.Exception base class, or derived from another inherited class therein. The full exception hierarchy of this error is:

Full Code Sample

Below is the full code sample we’ll be using in this article. It can be copied and pasted if you’d like to play with the code yourself and see how everything works.

This code sample also uses the Logging.cs helper class, the full code of which can be found here on GitHub.

When Should You Use It?

As discussed in the official documentation, the .NET framework includes a handy ApplicationDeployment class, which allows an application to perform programmatic updates and file downloads. A common technique for deploying .NET applications is using the ClickOnce technology, which is designed to make deployment of Windows Forms applications as painless as possible. The scope of using ClickOnce is well beyond the scope of this article, but suffice to say that most of the built-in functionalities of ClickOnce are usually good enough for most developing applications.

That said, sometimes you’ll need more control over how your application is deployed and, more importantly, how it is updated when new versions are released. For this purpose we’ll look at a simple example from the official documentation showing how to programmatically check for and download application updates.

For this sample we’ve created the Application.DeploymentException Windows Forms application Visual Studio. We’ve also added a TextBox control to Form1 with the name downloadStatus. Now let’s take a look at the code in Form1.cs:

We begin with the UpdateApplication() method, which starts by checking if the application is configured as a network deployed application. If so, we proceed to assign a few event delegates, then call the ApplicationDeployment.CheckForUpdateAsync() method, which checks the provided UpdateLocation for a new update.

The CheckForUpdateProgressChanged(object sender, DeploymentProgressChangedEventArgs e) method modifies the text of our the downloadStatus TextBox when progress of the download changes. We also use the GetProgressString(DeploymentProgressState state) method to indicate what is actually being downloaded at any given moment:

The CheckForUpdateCompleted(object sender, CheckForUpdateCompletedEventArgs e) method is where most of the actual business logic takes place:

Here we’re determining if the actual update check event resulted in an error and outputting that, otherwise we process a valid update, if required. Doing so invokes the BeginUpdate() custom method:

BeginUpdate() merely creates event delegations and invokes the CurrentDeployment.UpdateAsync() method, which performs the actual updating process.

The UpdateProgressChanged(object sender, DeploymentProgressChangedEventArgs e) method performs another simple text change indicating the update progress status, while UpdateCompleted(object sender, AsyncCompletedEventArgs e) determines if the update was successful, and whether the user wishes to restart the application.

Alright cool. Now the only thing left to do is to actually deploy our application and see what happens when we try to launch it. Since we’re explicitly performing an update check when the application loads, we’ll immediately get feedback on a successful or failed update process:

There are many ways to publish an application, but for this example we’re just using the Publish dialog for the project in Visual Studio. We’ll be publishing to the local publish\ directory, then we’ve specified the Update location to the UNC path of \\localhost\invalid\, which will cause the update process to look for the Airbrake.DeploymentException.application file in the invalid \\localhost\invalid\ path.

With our application now published let’s execute it and see what happens. As you can probably guess, a DeploymentException is thrown — specifically, the DeploymentDownloadException child class, indicating that the file could not be found at the specified location:

Not too surprising. Now, let’s try changing the Update location UNC path to match the local path where our Airbrake.DeploymentException.application file can be found (in the release directory). Publishing again, then performing a follow-up release build (to force a new version for the update script do detect) results in a successful remote update:

To get the most out of your own applications and to fully manage any and all .NET Exceptions, check out the Airbrake .NET Bug Handler, offering real-time alerts and instantaneous insight into what went wrong with your .NET code, along with built-in support for a variety of popular development integrations including: JIRA, GitHub, Bitbucket, and much more.