In the .NET Framework 2.0 and the .NET Framework 3.0, any ClickOnce application that installs on the system for offline availability must specify a deploymentProvider in its deployment manifest. The deploymentProvider is often referred to as the update location; it is the location in which ClickOnce will check for application updates. This requirement, coupled with the need for application publishers to sign their deployments, made it difficult for a company to update a ClickOnce application from a vendor or other third-party. It also makes it more difficult to deploy the same application from multiple locations on the same network.

With changes that were made to ClickOnce in the .NET Framework 3.5, it is possible for a third-party to provide a ClickOnce application to another organization, which can then deploy the application on its own network.

In order to take advantage of this feature, developers of ClickOnce applications must exclude deploymentProvider from their deployment manifests. This means excluding the -providerUrl argument when you create deployment manifests with Mage.exe, or making sure the Launch Location text box on the Application Manifest tab is left blank if you are generating deployment manifests with MageUI.exe.

Starting with the .NET Framework 3.5, you no longer have to specify a deploymentProvider in your deployment manifest in order to deploy a ClickOnce application for both online and offline usage. This supports the scenario where you need to package and sign the deployment yourself, but allow other companies to deploy the application over their networks.

The key point to remember is that applications that exclude a deploymentProvider cannot change their install location during updates, until they ship an update that includes the deploymentProvider tag again.

Here are two examples to clarify this point. In the first example, you publish a ClickOnce application that has no deploymentProvider tag, and you ask users to install it from http://www.adatum.com/MyApplication/. If you decide you want to publish the next update of the application from http://subdomain.adatum.com/MyApplication/, you will have no way of signifying this in the deployment manifest that resides in http://www.adatum.com/MyApplication/. You can do one of two things:

• Tell your users to uninstall the previous version, and install the new version from the new location.

• Include an update on http://www.adatum.com/MyApplication/ that includes a deploymentProvider pointing to http://www.adatum.com/MyApplication/. Then, release another update later with deploymentProvider pointing to http://subdomain.adatum.com/MyApplication/.

In the second example, you publish a ClickOnce application that specifies deploymentProvider, and you then decide to remove it. Once the new version without deploymentProvider has been downloaded to clients, you will not be able to redirect the path used for updates until you release a version of your application that has deploymentProvider restored. As with the first example, deploymentProvider must initially point to the current update location, not your new location. In this case, if you attempt to insert a deploymentProvider that refers to http://subdomain.adatum.com/MyApplication/, then the next update will fail.

For step by step guidance on creating deployments that can be deployed from different network locations, see Walkthrough: Manually Deploying a ClickOnce Application that Does Not Require Re-Signing and that Preserves Branding Information.

Reference