Deploying WPF Application with ClickOnce Deployment Techniques

Introduction to ClickOnce

There are many ways to deploy a WPF application from our development computer to an end user's desktop. Most WPF applications use one of the following deployment strategies.

1. Run in the browser: If we create a page-based WPF application, we can run it right in the browser. We don't need to install anything. However, our application needs to be able to function with a very limited set of privileges. (For example, we won't be allowed to access arbitrary files, use the Windows registry, and pop up new windows, and so on.)
2. Deploy via the browser: WPF applications integrate closely with the ClickOnce setup feature, which allows users to launch a setup program from a browser page. Best of all, applications that are installed through ClickOnce can be configured to check for updates automatically. On the negative side, we have little ability to customize our setup and no way to perform system configuration tasks (such as registering file types, creating a database, and so on).
3. Deploy via a traditional setup program: This approach still lives on in the WPF world. If we choose this option, it's up to us whether we want to create a full-fledged Microsoft Installer (MSI) setup or a more streamlined (but more limited) ClickOnce setup. Once we've built our setup, we can choose to distribute it by placing it on a CD, in an e-mail attachment, on a network share, and so on.

Is ClickOnce the right choice for deploying the WPF application?

It's technically possible to move a .NET application from one computer to another just by copying the folder that contains it, but any professional applications often require a few more frills. For example, need to add shortcuts to the Start menu or desktop, register file types, and set up additional resources (such as a custom event log or a database). To get these features, we need to create a custom setup program.

The older options which are available to use are

1. To use products like InstallShield.
2. Or we can create an MSI setup using the Setup Project template in Visual Studio.
3. Or choose any Traditional setup program that gives a familiar setup wizard, with plenty of features for transferring files and performing a variety of configuration actions.

Benefits that come with ClickOnce deployment

But the benefits that come with ClickOnce deployment are that it is integrated with WPF, with many limitations it offers two very important benefits.

1. Support for automatically downloading updates from the Web.
2. Support for installing and running applications in limited trust scenarios. This feature is available only if we create an XAML browser application (XBAP).
3. The most interesting part of a ClickOnce deployment is the way it supports updating. Essentially, we (the developer) have control over several update settings. For example, we can configure the application to check for updates automatically or periodically at certain intervals. When users launch our application, they run a shim that checks for newer versions and offers to download them.
4. We can even configure our application to use a web-like online-only mode. In this situation, the application must be launched from the ClickOnce web page.
   But don't we think that just these benefits are not enough to entice developers like us to give up the features of a full-fledged setup program? Well I agree, but if we see in the future, it becomes more common to run Windows using an account with limited trust i.e. vista, and as browser-based WPF applications become more widespread, ClickOnce will gain importance.

How ClickOnce Works

1. To what type of application is ClickOnce suitable? ClickOnce is designed with simple, straightforward applications in mind. It's particularly suitable for line-of-business applications and internal company software. Typically, these applications perform their work with the data and services on middle-tier server computers. As a result, they don't need privileged access to the local computer.
   ClickOnce may also make sense for consumer applications that are deployed over the Web, particularly if these applications are updated frequently and don't have extensive installation requirements.
2. Prerequisites of installation: For ClickOnce to install a WPF application, the computer must already have the .NET Framework 3.0 or 3.5 runtime, depending on the version that we're targeting. When we first launch a ClickOnce setup, a bootstrapper runs that verifies this requirement. If the .NET Framework runtime isn't installed, the bootstrapper shows a message box that explains the issue and prompts the user to install .NET from Microsoft's website.
3. ClickOnce Installation Model
   

Although ClickOnce is ideal for web deployment, the same basic model lends itself to other scenarios, including the following.

• Deploying our application from a network file share.
• Deploying our application from a CD or DVD.
• Deploying our application to a web server or network file share and then sending a link to the setup program via e-mail.

Note. The installation web page isn't created when deploying to a network share, a CD, or a DVD. Instead, in these cases, users must install the application by running the setup.exe program directly.

ClickOnce Limitations

The limitations of ClickOnce include the following.

• ClickOnce applications are installed for a single user. We cannot install an application for all users on a workstation.
• ClickOnce applications are always installed in a system-managed user-specific folder. We cannot change or influence the folder where the application is installed If ClickOnce applications are installed in the Start menu, they show up as a single shortcut in the form [Publisher Name] ➤ [Product Name]. We can't change this, and we can't add other shortcuts, such as a shortcut for a help file, a related website, or an uninstall feature. Similarly, we can't add a ClickOnce application to the Startup group, the Favorites menu, and so on.
• We can't change the user interface of the setup wizard. That means we can't add new dialog boxes, change the wording of existing ones, and so on.
• We can't change the installation page that ClickOnce applications generate. However, we can edit the HTML by hand after it's generated.
• A ClickOnce setup can't install shared components in the global assembly cache (GAC).
• A ClickOnce setup can't perform custom actions (such as creating a database, registering file types, or configuring registry settings).

Getting into Action with ClickOnce (Making WPF application a ClickOnce Application): Below are steps for deploying the WPF application.

Step 1. Go to Visual Studio

Right click project property, and select Publish

Step 2. Choose Build

Publish [ProjectName] from the Visual Studio menu, which walks through a short wizard.

Step 3. How to choose a location

There's nothing particularly important about the location where we first publish our application because this isn't necessarily the same location we'll use to host the setup files later.

To get a better sense of how this works, start by choosing a local file path location (such as c:\Temp). Then click next. We're now faced with the real question of whether users will go to install this application

In the below image, we have essentially three choices. We can create an installation for a network file share, a web server, or CD or DVD media. The following sections explain each approach.

Approach 1. Publishing for a Network File Share.

In this case, all the users in our network will access the installation by browsing to a specific UNC path and running a file named setup.exe at that location.

A UNC path is a network path in the form \\ComputerName\ShareName. We can't use a networked drive because networked drives depend on system settings (so different users might have their drives mapped differently).

Approach 2. Publishing for a Web Server

We can create an installation for a web server on a local intranet or the Internet. Visual Studio will generate an HTML file named publish.htm that simplifies the process. Users request this page in a browser and click a link to download and install the application.

Approach 3. Publishing for a CD or DVD

If we choose to publish to set media such as a CD or DVD, we still need to decide whether we plan to support the automatic update feature. Some organizations will use CD-based deployment exclusively, while others will use it to supplement their existing web-based or networked-based deployment. We choose which option applies for use in the third step of the wizard in the image below.

Here, we have a choice. We can supply a URL or UNC path that the application will check for updates. This assumes that we plan to publish the application to that location. Alternatively, we can omit this information and bypass the automatic update feature altogether.

Step 4. Checking for Online and offline updates: If we're creating a deployment for a web server or network share, we'll get one additional option, as shown in Figure below;

The default choice is to create an online/offline application that runs whether or not the user can connect to the published location. In this case, a shortcut for the application is added to the Start menu.

If we choose to create an online-only application, the user needs to return to the published location to run the application. (To help make this clear, the publish.htm web page will show a button labeled Run instead of Install.) This ensures that an old version of the application can't be used after we roll out an update. This part of the deployment model is analogous to a web application.

Understanding Deployed Files: For example, I have deployed an application named temp to my laptop location

c:\Test, so I have files like these.
c:\Temp\setup.exe
c:\Temp\publish.htm
c:\Temp\Temp.application
c:\Temp\Temp_1_0_0_0.application
c:\Temp\Temp_1_0_0_0\Temp.exe.deploy
c:\Temp\Temp_1_0_0_0\Temp.exe.manifest

1. The publish.htm file is present only if we're deploying to a web server.
2. The .manifest and .application files store information about required files, update settings, and other details
3. The .manifest and .application files are digitally signed at the time of publication, so these files can't be modified by hand. If we do make a change, ClickOnce will notice the discrepancy and refuse to install the application.
   So now our application is the ClickOnce application

Finally, we are now ready to install a ClickOnce Application

To see ClickOnce in action with a web deployment, we will follow these steps

1. Make sure that we have the optional IIS web server component installed.
2. If not installed, follow these easy steps, for Windows XP, choose Settings ➤ Control Panel ➤ Add or Remove Programs from the Start menu, choose the Add/Remove Windows Components section, and scroll through the list until we find Internet Information Services (IIS).
3. Using Visual Studio, create a basic Windows application and compile it.
4. Launch the publishing wizard (by choosing Build ➤ Publish), and select http:// localhost/TyrePro for the publish location. The localhost portion of the URL points to the current computer
5. Choose to create an online and offline application, and then click Finish to end the wizard. The files will be deployed to a folder named TyrePro in the IIS web server root (by default, the directory c:\Inetpub\wwwroot).
6. Run the setup.exe program directly, or load up the publish.htm page and click Install. We'll receive a security message asking whether we want to trust the application (similar to when we download an ActiveX control in a web browser)
   
   
   
7. If we choose to continue, the application will be downloaded, and we'll be asked to verify that we want to install it.
8. Once the application is installed, we can run it from the Start menu shortcut or uninstall it using the Add/Remove Programs dialog box.
   

Updating a ClickOnce Application

To see how a ClickOnce application can update itself automatically, follow these steps with the installation from the previous example:

1. Make a minor but noticeable change in the application (for example, adding a button).
2. Recompile the application and republish it to the same location.
3. Run the application from the Start menu. The application will detect the new version and ask whether we'd like to install it
4. Once we accept the update, the new version of the application will install and start.

How to configure ClickOnce Options

If we follow the publishing wizard to create ClickOnce deployment, it doesn't allow us to adjust all the possible options. To get access to more ClickOnce settings, double-click the Properties node in the Solution Explorer, and then click the Publish tab. we'll see the settings shown in the Figure below;

Let us understand each option under the Publish Tab

1. Publish Version: The Publish Version section sets the version of our application that's stored in the ClickOnce manifest file. This isn't the same as the assembly version, which we can set on the Application tab, although we might set both to match.
   The key difference is that the published version is the criteria that are used to determine whether a new update is available. If a user launches version 1.5.0.0 of an application and version 1.5.0.1 is available.
2. Updates: The Updates button isn't available if we're creating an online-only application. We first choose whether the application performs update checking. If it does, we can choose when updates are performed. We have two options
   
   Before the application starts. If we use this model, the ClickOnce infrastructure checks for an application update (on the website or network share) every time the user runs the application. If an update is detected, it's installed, and then the application is launched. This option is a good choice if we want to make sure the user gets an update as soon as it's available.
   After the application starts. If we use this model, the ClickOnce infrastructure checks for a new update after the application is launched. If an updated version is detected, this version is installed the next time the user starts the application. This is the recommended option for most applications because it improves load times.
3. Options: The publisher and product names are used to create the Start menu hierarchy. We can also use the Publish Options dialog box to change the name of the installation page in web deployments (which is publish.htm by default)
   

Conclusion

1. ClickOnce deployment model, which was introduced in .NET 2.0 and remains a good choice for deploying stand-alone WPF applications.
2. With XBAPs, ClickOnce entails certain compromises—for example, we need to accept compromises about certain client configuration details we can't control.

Thanks for reading