Deployment Activities

You can use Visual Studio to publish an application with a single step. When Visual Studio publishes an application, it includes project files and references that have been configured as application files on the Publish tab of the project Properties window. By default, this includes the application executable file, configuration file, any referenced libraries, and project files that have the Build Action property set to Content. This means that if your application depends on other libraries or files that it dynamically loads, they will not be published with your application if they are not part of your project. For example, the Stock Trader Reference Implementation (Stock Trader RI) application holds project references to all of its modules and uses static loading of those modules in the bootstrapper. As a result, you can simply publish the reference implementation and launch it with no modifications of the manifests. However, with Composite WPF applications that use dynamic modular loading, you usually do not reference modules that will deploy with the shell because the shell is designed to be decoupled from the modules that will load into it at run time. As a result, you need a way to include your modules and any other dynamic dependencies into the ClickOnce publication. Likewise, if your deployed application needs additional resources, such as data files that the modules depend on that are not part of the shell project, you will need to update the ClickOnce publication to get it to deploy those dependencies as well.

The .NET Framework SDK includes the manifest tools Mageui.exe (a Windows UI application) and Mage.exe (a command line tool). These tools are collectively referred to as Mage. With these tools, you can create manifests or modify manifests after they are published from Visual Studio. With Mage, you can access most, but not all, of the content of a manifest. For example, you can use Mage to add all application files from a single folder, but you cannot add multiple files from different paths. Mage does not support all the publishing scenarios addressed in this topic. Specifically, it does not allow you to add application files that reside in different folders, even though the ClickOnce deployment mechanisms in the .NET Framework runtime support deploying application files that reside in different folders on the server. Mage also has the disadvantage that, because of its low-level access to individual settings in individual manifests, it makes common publishing scenarios more complex than they need to be.

The Manifest Manager Utility is a custom utility that supports all the scenarios in this topic with a more automated approach. This utility uses the API exposed through the Microsoft.Build.Tasks.Deployment namespace. You can consult the code for the Manifest Manager Utility in this package as an example of how to use that API to obtain low-level and full access to the manifest manipulation API.

The key classes used in this utility are the ManifestReader, ManifestWriter, DeploymentManifest, ApplicationManifest, and X509Certificate2 classes.

This section describes activities that developers perform when publishing and deploying composite WPF applications with ClickOnce. Where appropriate, the activities are described using both the Manifest Manager Utility (automated) and Mage (manual) so that you can see the steps the utility automates.

To use ClickOnce deployment, you must have an application that is ready to deploy. Because publishing applications that use dynamic module loading is the more challenging case, the following How-to topics use the ConfigurationModularity QuickStart as the application that is being deployed:

Home page on MSDN | Community site