Deploying for Multiple Groups

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies.
This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
To create client business applications using current Microsoft technologies, see patterns & practices' Prism.

A common requirement is to have different application functionality exposed to different sets of users based on their roles. The roles might correspond to functional roles, such as customer, teller, and branch manager, where you want to expose distinctly different functionality to each role. Alternatively, the roles might correspond to some other type of group distinction, such as end users, beta testers, Q&A, and developers, where each role sees roughly the same functionality, but each role actually executes a different code base to get that functionality. For the purposes of this guidance, a division that requires different users to execute different code bases is considered to be a group.

You can use the role-based security in the .NET Framework to determine a user's role at run time and change the behavior of the application based on role. For example, as your form loads, you can check whether the user is a branch manager. If the user is not a branch manager, you can make certain options on the screen unavailable. When using the Composite UI Application Block, you can set roles for different modules in the profile catalog and use the catalog entries to determine which modules are available to each role. Between these two capabilities (using role-based security, and defining role-module relationships in the catalog), you can handle requirements for role-based modification of application behavior by using a single code base.

ClickOnce can be used to provide different code bases for different groups. A single user can be part of a single group or multiple groups. If a user is part of multiple groups, the user needs to be able to run multiple versions of the application on the same computer at the same time. An example of this is a developer or tester who wants to be able to run both the beta version of an application and the production version of the same application side by side to compare functionality or features.

To meet this requirement, you can publish multiple versions of your application to the deployment server and direct users in different groups to the appropriate deployment manifest for the version that you want them to run.

Typically, when you use ClickOnce to publish a new version of your application, the default deployment manifest is overwritten by the new version's deployment manifest, and there is no way for client computers to deploy and run the earlier version from the server. If the application is configured to check for updates, it will detect the new version and will be updated the next time it connects to the deployment server.

In fact, the installation engine in ClickOnce also uses the deployment manifest name to help distinguish individual applications. This means that even if you publish two different versions of your application with two different URLs, you will not be able to run them as separate applications on the same computer from the same user account unless they have different deployment manifest names. When the second application is deployed to the client computer, it overwrites the deployment information for the first application if the deployment has the same deployment manifest name. As a result, the usual versioning behavior of ClickOnce is not sufficient for you to execute more than one version of an application on your computer at any one time.

When you publish multiple versions of your application to target multiple groups, you have to distinguish them with different deployment manifests, each having a unique deployment manifest name. The different versions of the application do not necessarily have to be distinguished by version numbers, although they should be. Because the deployment manifests have unique names, the URLs to them will be different; therefore, the client computer will see the different versions as separate and distinct applications and will install both versions of the application on the client computer and allow them to run side by side.

When you use Visual Studio to publish an application, it uses the assembly name to set the deployment manifest name. You can also use Mage to modify the manifests after you publish them with Visual Studio. You should also change the product name for the second deployment so that you can distinguish between the two entries on the Start menu. For more information about how to support multiple user groups by using deployment manifest naming, see How to: Publish Different Versions for Different Groups.